“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
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
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.
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.
Thanks to Jason Garber for his thoughts on an initial draft of this post.