Why JavaScript Frameworks

This year brought a lot of commentary about the death of the web, site obesity, and how the tools we use on the frontend are killing the web. Much of this centers around the ever-increasing use of JavaScript frameworks like Angular in an attempt to emulate native apps on the web. Something about these conversations didn’t sit right with me. I kept asking myself, if these are so detrimental to the web, what is driving their enormous popularity? There are tons of frameworks and more coming on the scene all the time. So where is this all coming from? The latest in this set of articles was from Zeldman in A List Apart. His article isn’t directly about the JavaScript frameworks themselves, but the following sentence refocused this question for me.

“I feel your pain today worse than ever, as three quarters of our industry gets high on these bloated frameworks, and abandons core principles like progressive enhancement and building lean.” — Zeldman

I want us to dive deeper into why these frameworks, and the development process they foster is so popular. For those of us who wish to counter this effect, I think it’s important to understand the drivers behind this trend. Here are some initial thoughts on why they have become popular.

Backend Developers Doing Frontend

Over the years, JavaScript has matured. It has also become more standardized in browsers, and thus easier to work with. This seems to have had the effect of backend developers softening their hatred of it, and have begun working in it. I think also the rise of languages like CoffeeScript that abstract the creation of JavaScript make it more palatable.

With the rise in popularity of Rails, and it’s ability to automagically do stuff for you, a culture of abstraction hit the mainstream. Rails added CoffeeScript, jQuery, and Sass with version 3.1. If you can add languages and frameworks that abstract the frontend layer and make it appear more like your server code, it opens the door for backend developers to get involved in the frontend. CoffeeScript lets you abstract JavaScript, and jQuery handles a lot of cross-browser oddities for you. (I quite like jQuery but it abstracted the details of JavaScript away for me, to my detriment.) Similarly, while not as popular as other formats, HAML allows you to abstract your HTML. Sass is the only language that clearly resembles what it transforms into; so you do need to know the basics of CSS to write it. These abstractions fit nicely in the framework mindset where things are magically done for you.

Rise of the Full-Stack Developer

The outcome of this seems to be the birth of the full-stack developer. These are developers who know frontend, backend, and all ends in between. A great full-stack developer seems more of a unicorn than a designer who codes, but they’re in so much demand. I think the abstractions we have created make it easier to be such a developer, but it seems that the developer is still incomplete. Based on the job postings I’ve been seeing, a full-stack developer is really a backend developer who understands how the abstractions work. And the abstractions work when they are grouped together under a framework’s umbrella. The framework lets you write this stuff quickly. Not necessarily well, just quickly.

Looking for the Exit

The increase of backend developers working on the frontend, or transitioning into full-stack developers isn’t necessarily a bad thing. They can learn robust frontend development techniques like progressive enhancement, just like they can learn about a new database or new JavaScript framework. However, I believe a more substantial impediment exists that is a disincentive for them to learn how to build progressively-enhanced, future-friendly web products. The Exit.

Silicon Valley seems focused, maybe even obsessed, on the exit – either through acquisition or IPO. I’ve been looking for a new job and have come across postings where they mention how many startups the founder has previously founded. Why is that a metric, let alone a metric of success? There’s no expectation that something will last. If a company isn’t meant to last, why take the time to build a product that’s built to last? If there’s no future expected for your product, why make it future-friendly? In the build-to-exit environment, you need tools to help you build things as fast as possible. If your launch takes too long, you can miss your chance to blow up and get your exit because someone beat you to it. Progressive enhancement might take you too long to launch. And the amount of extra time likely feels significantly longer to people eyeing the exit.

In Summary

Abstractions can make our lives easier as developers. But they can hide away important details about how particular pieces work and can be optimized. If you start with the abstractions, it can be much harder to get this right.

Writing solid frontend code isn’t the easiest. There are lots of moving pieces – browsers, operating systems, proxies, users – that make it complicated. If you don’t understand the history of web standards, it’s hard to know how to make these things work well. If you’re used to a single runtime, which you control, the frontend can be a terrifying place. You’re not going to want to support hundreds or thousands of runtimes. You’re going to want a framework that handles all this mess for you. You might even want to go so far as to only support the browser you use and purposefully exclude ones you don’t. You now have a “single” runtime on the frontend.

Combine this situation with a desire to get to market as fast as possible. If you’re first, you have a better chance of getting the attention of someone who might be interesting in buying you out. It really seems less about building products people will use for a long time and more about getting a huge payday when you sell. The venture funded, exit-seeking environment of the Valley is a huge disincentive to spending the time to learn the ins and outs of the frontend (and backend for that matter). Abstract the frontend away like we do our server-side frameworks.

I think if we’re really to understand the growth and popularity of JavaScript frameworks, we need to understand the environment in the industry that leads to their rise and that sustains them. If we want to make them better frontend citizens, this understanding is critical to combatting the parts of them that undermine the work we’ve done over the last 15 years fighting for web standards. It seems as much an education project as web standards was (and remains).

Thanks to Jason Garber for his thoughts on an initial draft of this post.