Most programming languages support a small number of popular, stable application frameworks. Objective-C and Swift apps use Apple’s excellent Cocoa framework. Ruby apps more often than not use Rails. Java has a handful of established web app frameworks, and they come and go relatively slowly.
Meanwhile, the browser itself changes far more rapidly and unpredictably than the underlying languages on which other frameworks are built. The browser has changed more since Backbone.js debuted in 2010 than Objective-C has changed since Cocoa debuted all the way back in 1988. Browser improvements that inspire new generations of frameworks happen constantly.
These inputs fuel an incredible amount of experimentation, excitement, and adaptation. Every day new frameworks, new approaches, and new tools erupt from the geyser we call Github. Every year there are more instant-classic JSConf talks about crazy new ideas, impressive new browser features, and rethinking best practices. This beautiful chaos is exciting in a way that I’ve never seen in another developer community.
Unfortunately, while the community is busy driving new features and new frameworks, the browser is is busy killing them.
Unlike the frameworks we use in C++ or Swift, the entirety of your app framework must be downloaded, parsed, and turned into machine code before users even see your app. Caching and offline access continue to improve, but the very real constraints on bandwidth, latency, memory, and loading time are a huge challenge for the kind of huge app frameworks that we take for granted in native app development.
The churning seas on which client-side frameworks sail are especially treacherous for large, ambitious frameworks that try to create a rich environment and UI library for building apps the way we do natively.
The well-regarded Mithril.js framework is only 5kb. That’s great for load and parse time, but it necessarily can’t solve a rich array of problems. Rails, by contrast, has more than 100x as much code. Just ActiveRecord is 1274kb! In the browser, you can’t sanely use a 1.2MB framework, and so the proliferation continues.
Neck deep in frameworks, choosing one we’re actually happy with becomes virtually impossible. The Paradox of Choice means that knowing you’re probably not using the right framework causes endless cognitive dissonance. Ironically, this dissatisfaction drives even more people to create their own frameworks.
Yes, Angular,js, the framework that I initially described in 2009 as “unreasonably weird” seems to have achieved a level of popularity that no JS app framework ever has. Between serious support from Google, an easy ramp-up path, and a rich community, Angular looks poised to finally settle the…
Wait, what’s that? The Angular team has decided that Angular 2 will not be compatible with Angular 1.x, and there will be no easy upgrade path?
Developers familiar with the Angular 1.X will encounter a drastically different looking framework and will need to learn a new architecture.
Is this forever?
Maybe I should just call off the hunt. Though, people do seem pretty excited about React.js. They have some smart developers and exciting ideas, at least from what I’ve seen.
You know, maybe I should build something new with it and see what it’s like. Maybe… maybe it’s the one.
Special thanks to Henrik Joreteg, Angelina Fabbro, and Nigel Brooke for their feedback on the ideas behind this piece.
This article has been translated to Japanese.