Abstractions are powerful, but come with danger.

[jlengstorf]

Another section that got cut that I want to use later.

Modern tools and frameworks give developers superpowers

Modern tools and frameworks have made things that used to be prohibitively difficult possible for absolute beginners. With just a few lines of code, we can dynamically bind an input’s value to another element on a page. In the DHTML days, this was an expert-level request; today, it’s taught as a “hello world” example by modern JavaScript frameworks.

These improvements come from introducing abstractions. Developers tend to simultaneously love and hate abstractions: we tend to love the abstractions that helped us learn, but we hate the abstractions that make the stuff we’ve already learned easier for other developers.

Feelings aside, the fact remains developers live in a world of abstractions, from compilers to development environments to frameworks. And each of these abstractions has an impact on our developer experience.

Some abstractions changed our whole industry: jQuery made JavaScript accessible to an entire new generation of developers. Other times, they’re small conveniences that add up to huge time savings: tools like Autoprefixer and Prettier have likely saved millions of developer hours by automating small chores in our workflows so we don’t have to think about them.

In the front-end world, these abstractions have created so many possibilities that we’ve started to complain about it, publishing op-eds about JavaScript fatigue and starting Twitter fights about whether stylesheets should be moving into JavaScript.

Regardless of how we feel about any particular abstraction, there’s no denying that it’s now easier than ever before for developers to create incredible apps. The tools and environments we work in are better designed to let us focus on creation rather than struggling with the low-level details. On average, DX today is objectively better than it’s ever been before. (That’s not to say, however, that it’s as good as it could be.)

Don’t forget the community and ecosystem

Beyond the enhanced capabilities and simplified workflow offered by modern tools and frameworks, there’s also the community aspect. Developers around the world are all using the same tools, meaning we’re able to trade support and insight with total strangers.

Popular open source frameworks have active forums and chat rooms, huge back-catalogs of tutorials and deep dives, active issue trackers, local meetup groups dedicated to using them, and even conferences dedicated to pushing the technology forward.

On top of that, there’s an extensive ecosystem around many of the most popular tools, full of plugins, extensions, and add-ons to make tasks that were murderously difficult in the past into trivial configuration tweaks.

For example, consider optimizing images for the web. For a time, this was only possible with deep knowledge of the various image formats. Then, a few developers built command line utilities to optimize images, but these were manual processes that still required a decent amount of knowledge to get the settings just right. More recently, services like TinyPNG have created abstractions around those command line tools so that optimizing images is as easy as sharing them on social media. Or, even better, these tools can now be stuck into a build pipeline so that humans don’t even need to be aware of it at all; it just happens, and the world is a better place for it.

Good abstractions put the right guard rails in place

Another advantage of modern tools and frameworks is they establish best practices and tend to enforce them through convention.

Putting the right guard rails in place is critical for the success of any app with two or more developers, because they help guide decision making toward doing the best thing according to the project’s goals. By choosing abstractions with guard rails that match your app’s needs, you’re able to make the right thing the easy thing — your team will make good decisions by default, and that’s an enormous benefit to any project.

We haven’t even touched team dynamics yet

It’s beyond the scope of this article to go into detail here, but we can’t talk about DX without bringing up its effect on a company’s ability to attract the best talent. If the company is using a stack that developers are excited to work with, it becomes that much easier to convince someone to join the team.

In contrast, if the stack is one that developers dread or that’s known to have a poor DX, it can be tough to hire high-quality developers, and even harder to keep them around.

The dark side of DX

The downside of improving DX through abstractions, though, is that relying on abstractions built by other people means accepting the opinions, decisions, and limitations of those people. Tools and frameworks are built from a particular point of view: for example, ReasonML is (in part) an assertion of its authors’ belief that type safety is worth limiting some of JavaScript’s flexibility. That’s neither a good nor a bad thing, necessarily, but choosing to use ReasonML is choosing to build your apps according to that worldview.

When we choose an abstraction, whether it’s a language, a tool, or a framework, we’re also choosing to live with the opinions of the people who built that abstraction.

One example of developers being bound by their abstractions is WordPress, which infamously maintains support for out-of-date versions of PHP, limiting the ability of developers to use newer features of the language inside their WordPress themes and plugins.

If the developers who maintain your tools and frameworks don’t share your goals, it can lead to problems ranging from naming disputes (#teamsmoosh) to breaking the internet.