Update 28/1/2016: This post was about Angular 1, it was published well before Angular 2 was even near ready for beta release. A bit has changed since then, but my thoughts on Angular in this post have not.
For quite a long time developers have been using AngularJS. Coming at a time when the alternatives were the likes of Backbone.js (while powerful in its own right), which just didn’t tick all of the boxes a modern web application needs ticked, we thought we had reached developer nirvana.
We got two-way data binding, controllers, directives and templating syntax. For a good while things were peachy, the sun was shining and everyone was sipping from the golden chalice of AngularJS kool-aid. We put it on t-shirts, wrote books, online training courses, bumper stickers and they sold baby, they sold.
As modern web application development evolves at a steady pace, the number of Javascript frameworks out there to choose from is staggering. It seems everyone has a Javascript framework, 10 new Javascript frameworks will probably come out by the time you finish reading this article.
While AngularJS is far from dead, its eventual demise is coming. A slew of core problems with the framework, more notably dirty-checking and transclusion was enough to rally the detractors to write blog posts about why you shouldn’t use AngularJS. They were all right in their own special way, but some were missing the point.
Not too long ago there was no viable alternative to AngularJS. I am not just talking about feature-set or community participation, I am talking about the lack of actual backing by anyone other than a few neck-beards in their basements contributing to their beloved open source project.
While there are some great Javascript frameworks out there, not many can guarantee with almost absolute certainty that they’ll be around tomorrow (not even Angular could do that, but the Google backing was reassuring).
This is where AngularJS succeeded. The everyday developer loved it, people were using it with WordPress and pretty much anything they could stuff Angular into. And then the enterprise started using it, all of a sudden you were seeing listings for local council and government jobs that listed AngularJS as a desired skill.
But why? If other choices were out there, why did Angular succeed? Was it because it was the first one out of the gate to offer almost everything you would find in a server-side framework or was it the fact it was backed by Google? In part it was both. But there was one other aspect of Angular that made it appealing.
I think it is safe to say that many took comfort in the fact that Google was behind Angular and if Google was behind it, then it must be good. This kind of trust in Google surprises me given their poor track record sunsetting a whole lot of products with their backing, more notably Google Reader.
Instead of trying to replace HTML, Google strengthened it. Decorating HTML with custom attributes, elements and control directives was a hit with everyone. Instead of having to create nested objects in a Javascript file, you were working in HTML and then using said decorations to make things happen in Javascript when you were ready.
It was Lego (AngularJS) vs Meccano (every other framework).
While the disdain for Angular was strong, the love that people had for it remained the strongest. For every hate-piece on Angular, there was a retort that would follow soon after.
The fighters and lovers were on equal footing, kind of like a war. One side spews propaganda and the other side does their best to dispel it: the PHP language is all too familiar with this ugly side of development.
“This ain’t a scene, it’s a god damn arms race” – Fall Out Boy.
When things go wrong
A little while ago talk of Angular 2.0 came about. Instead of it being a natural evolution of the framework, it was revealed that it would be a complete rewrite. The backwards compatibility, transclusion and most hated of them all: dirty-checking would either be removed or rewritten in a more efficient manner in 2.0.
But the Angular team did something that no open source project in a highly competitive battlefield should do: they announced a new version of their highly popular framework that would have no backwards compatibility with the 1.x branch and that there would be no upgrade path whatsoever.
gasp
When the Angular team announced this, you could practically hear a record skip right across the Internet. The concern started relatively contained with the Hacker News comments section and then it escaped, soon everyone was writing blog posts defending the new syntax and lack of backwards compatibility, but many were decrying such a move.
Not only did they announce there would be no backwards compatibility or upgrade path, they also revealed a controversial new syntax for decorating your HTML markup.
Why were people so angry? The Angular team announced they would be addressing all of the shortcomings in version 2.0, that transclusion you hate so much? Gone. Dirty-checking? Completely rewritten to be more memory efficient and use browser object-observe when supported.
Even though at its core 2.0 would arguably be a much better successor to Angular 1.x, removing a large chunk of backwards compatibility and starting from a clean slate, for a version 2.0 the Angular team shocked by changing too much, too soon.
It all comes down to the fact that it is a universally accepted downside of Angular that it has a steep learning curve. The basics of Angular not so much, but the more nitty gritty aspects of the framework were arguably harder to learn due to confusing documentation and confusing blog posts that would go against some of the things the documentation would tell you to do.
You could say that AngularJS 2.0 was a message: every developer that had spent their time learning the framework were being told mostly everything they have learned would be invalidated in possibly 12 months time when 2.0 is released.
It’s like learning French only to discover that in 12 months time that all French speaking nations would be switching to Italian, sure there might be some similarities but it is a completely new language you have to learn.
The biggest controversial aspect of Angular 2.0 was not just the lack of upgrade path, it was the new syntax which looked ugly. There were concerns it would also throw HTML validation (some people still run their sites through the W3C validator surprisingly).
It would take a little bit of time after for the Angular team to sit back and realise they had made a big mistake. Their stubbornness had already caused Rob Eisenberg (of Durandal fame) to abandon the Angular 2.0 team and build a successor to Durandal in the form of Aurelia. While the Angular team might not have realised it, losing Rob was actually a big blow to the project.
Now we are seeing Angular 2.0 components being ported back to 1.4 and while the 1.x branch will continue to be supported for a little while, the damage has been done. Even though there will now be an upgrade path (sort of), it is too little, too late.
Death is near
Even though AngularJS 2.0 has yet to be released, many have abandoned it already. There are a few great choices out there for starting your next Javascript framework like Aurelia or React.js. Those still using AngularJS are supporting legacy applications or junior developers completely unaware of the changes taking place around this framework and the framework space in general.
Having said that: not everybody will abandon AngularJS and support for the 1.x branch will continue for some time. However, once 2.0 lands, it would make very little sense to use the older and more troublesome 1.x branch.
While AngularJS 1.x will remain popular for some time yet, make no mistake React.js alone in its relatively short lifespan has taken an axe to Angular’s market share quite significantly and we will see those effects ten fold when Angular 2.0 is released.
This coupled with other frameworks like Aurelia and EmberJS which has seen a massive uptake by developers, Angular is not the only kid in the playground anymore.
Angular is not going anywhere in the interim, but I think there is now enough competition in the space that simply being backed by Google is not enough to convince developers to stay and trust their decisions are the right ones.