This article originally appeared on the Divshot blog. Divshot is a developer-focused platform for deploying modern front-end applications. It was also started with Intridea’s support by Michael Bleigh!
If you follow the front-end world even a little bit, you’ve probably seen the internet explode over the massively incompatible rewrite that is AngularJS 2.0. Some think the Angular team has lost their marbles. I’m not so sure.
Angular is dominating the story for modern front-end frameworks right now. Even if it’s not your personal favorite, you have to admire its meteoric rise. It’s a rare case of a library achieving massive adoption from both the startup and enterprise set in a very short timeframe (it took Rails years to get buy-in from bigger businesses). The Angular team is sitting on top of the world, and what do they decide to do? Rewrite the whole thing from scratch.
Are. They. Insane? Rewrites-as-new-versions have horror stories right out in the open! Python 3.0 was released nearly six years ago and still has a puny fraction of code being written for it. Enterprise developers have only just convinced their bosses to let them build with modern web tech, and now they have to sell them on either a massive rewrite of existing code or an 18-month support death clock. The hubris of the Angular team is unmatched since the times of Marie Antoinette!
Except, that’s not what’s really going on. The Angular team isn’t squandering their community goodwill out of sheer capriciousness. Instead they’re doing something risky: they’re pro-actively disrupting their own product before it’s rendered irrelevant by external competition.
But Michael, I hear you thinking, you just talked about how dominant AngularJS is. Shouldn’t they be taking steps to reinforce their leading position rather than putting the whole project in jeopardy?
That’s certainly an approach they could take, but I believe it would ultimately lead to Angular falling by the wayside two to three years from now.
The Innovator’s Dilemma
An oft-referenced issue in the tech world is the Innovator’s Dilemma, as described in a 1997 book by Clayton Christensen. Wikipedia summarizes it thusly: “successful companies can put too much emphasis on customers’ current needs, and fail to adopt new technology or business models that will meet customers’ unstated or future needs…such companies will eventually fall behind.”
I’ll admit that I hadn’t been following the progress of the Angular 2.0 design docs very closely. I had heard with interest about the new persistence layer, but hadn’t done much other investigating. Today I spent a bit of time perusing some of the content, and the real purpose of the rewrite started to make sense to me.
AngularJS 2.0 is a concerted effort to make sure that Angular remains relevant in the coming front-end world dominated by Web Components.
Sea Change Is Coming
I’ve written before about how Web Components are revolutionary. I strongly believe that in a few years they will become the dominant paradigm for front-end development. Web Components are not, however, in direct competition with modern front-end frameworks like Angular, Ember, or React. Instead, they are a new set of foundational technologies that will enable radically different and more powerful ways of building applications in the browser.
How is this related to Angular 2.0? The evidence is plain. As I browse through the design docs, I see at least six that reference Web Components directly or allude to related subjects. The Angular team is taking everything they’ve learned about building an application framework and building a brand new one for the Web Components world.
This is a brave and risky decision, but one that I think has a greater chance to protect Angular’s market leadership than threaten it. There is not (yet) an accepted set of best practices for using Web Components to build applications. Polymer works at a lower level than an application framework; in fact, it’s quite likely that application frameworks will emerge that are built on top of Polymer.
If Angular 2.0 arrives on the scene as the first comprehensive application framework for Web Components, and it’s also good at that job, it could see massive adoption, and not just from the existing Angular userbase.
What’s Next?
There’s no doubt that the recent firestorm will tarnish Angular’s reputation a bit. Someone who is researching which framework to use today might see the uproar and decide to turn elsewhere. Open source projects are just as vulnerable to brand perception as companies, and I think the Angular team needs to get out in front of it. Firmly establish the basis and need for change while reassuring developers that 1.X users won’t be abandoned wholesale. Acknowledge that incompatibility is a massive pain and demonstrate awesome new stuff that makes the pain worth it.
It’s an exciting time to be building apps in the browser, but it’s also a turbulent one. Angular has done a great job of introducing a huge audience to sophisticated front-end development, but the last couple years are just a warm-up act to the true front-end revolution. Angular 2.0 seems a bit crazy now. Looking at the bigger picture, however, it might just be crazy like a fox.
Update: Two Roads Diverged
Since I finished writing this post, two interesting and relevant bits of content have been published. Tom Dale wrote about The Road To Ember 2.0. The Ember team is taking a gradual, migration-focused approach to integrating new technologies like Web Components, DOM-based templating, and other new tech. They call this “Stability Without Stagnation.” Henrik Joretag of Ampersand wrote to Optimize for change. It’s the only constant about how they are taking the “lots of little modules” instead of an all-in framework approach.
These are both smart, valid, and potentially wildly successful approaches. The fact that there are different teams of smart people building software to make the front-end better, and that those teams have different and directly conflicting philosophies is fantastic.
Maintaining large, popular open source projects is really damn hard. It’s even harder when that project is a framework, because they are so deeply intertwined with users’ application code. If you move forward gradually, you risk stagnation. If you move forward in great leaps, you risk leaving behind those who don’t have the time and energy to leap with you. Like most things, it’s not a question of good and bad, it’s a question of risk and reward, of tradeoffs.
