With Angular 5 having been released in October, is it ok to restore to this oft-questioned framework the respect it once commanded? Have we gotten past the missed deadlines, the bifurcation blues, and the React wars? Can a development manager make a safe bet on Angular for the future? In this article we take a look at the state of things from a macro view. Ultimately, the situation seems pretty hopeful, though still not perfect. Caveat emptor.
In the Beginning
Angular (the first version) hit the streets around 2012, and by 2013 it had become the most prominent node-based framework for building web apps. Indeed it was one of the most prominent frameworks overall for new apps, slowly but surely converting JEE adherents (or at least, getting some jealous side-eye). With the advent of HTML5/CSS3 in 2014, and relatively complete support appearing in browsers in 2015, the ability to host client-side logic where it belongs, on the client, became a very compelling approach. The trend toward RESTful web services fit perfectly, and the overall simplicity of the ecosystem contrasted favorably with the complexity of JEE. This approach, being new, suffered from a scarcity of good development paradigms, a necessity on larger projects. In stepped Angular to fill that gap.
Angular was based on JavaScript, a browser-native technology (with a lot of shims, yes, but still having a decent shot to work in more than one browser version). Coupled with the excellent TypeScript, Angular was the first NSA environment (No Stupid Appserver) robust enough for real application development. The Angular framework espoused the battle-tested MVC approach (closer to MVVM actually but let’s agree, at this level, there’s not much difference). It had Directives and Templates to help you build modular, reusable widgets. And best of all, it had automatic two-way data binding, treating both Model and View as first class citizens, each entitled to know, at all times, what the other is up to.
For serious professional development, the combination of Google stewarding Angular itself, and Microsoft giving a heavy assist with excellent complementary technologies such as TypeScript and ReactiveX, gave a feeling of security for the development manager who chose Angular. TypeScript is a superset of JavaScript, which facilitates superb tooling for IDEs such as Visual Studio and its little brother, Visual Studio Code (which runs on Linux and Mac). ReactiveX implements an excellent paradigm for handling asynchronous streams, and can provide big design and productivity boosts for development teams who adopt it.
Angular was so great, of course it couldn’t last. Two-way data binding was so useful, and getting it for free let developers focus on screwing up their apps in other ways. Why labor to create efficient, maintainable code when the framework abstracts all the plumbing that used to plague your maintenance hours? We could add poorly thought out features quickly and easily with time to spare, and it would be a long time before the development manager figured out the beast was unmaintainable and a performance nightmare. By then, we’d be on another project.
Kidding aside, Angular, back then, really was a victim of its own success. The “watcher” approach as a construct for supporting two-way binding was largely abstracted away, and consequently not well-understood by developers, many of whom unknowingly pushed it beyond its limits. The internal architecture of Angular, combined with the framework’s productivity, created the perfect storm for performance bottlenecks. This was really bad, because once there, it was usually not easy to bring it back. Having to subtract features to salvage performance is an ugly place for a development team to be. And because the framework was so new, and so successful, there was a real shortage of developers with enough technical know-how to avoid a team’s getting into trouble.
Google’s Angular team quickly grasped the problem, and came to a very stark conclusion: version 2 of Angular would have to be radically redesigned. Worse, it was clear that Angular 2, if it was to achieve all of its design goals, could not possibly be backward-compatible with Angular 1. They had to kill the patient to save it. At this writing, we still don’t know if it worked, though the prognosis is improving.
Growing Pains
The Angular team’s realization that Angular 2 would not be backward compatible took shape in 2015. The timing of this decision, even more than the dramatic nature of the change itself, is probably the single greatest reason why Angular today is still facing an upward climb to adoption, and still in competition with tools such as React, Vue, and others which if not necessarily inferior, are certainly less ambitious. By 2015, many early adopters had already completed and deployed successful projects using Angular, and were ready for more. At that time, these people comprised the commercial heart of the Angular community, not only its present, but its future leadership (by “commercial” I don’t necessarily mean “for profit,” but rather everybody who was using Angular mainly for projects, not including those who were experimenting, evangelizing it, teaching it, etc.).
By 2015, the early adopters’ first projects were in maintenance mode. Innovative, good-looking, feature-rich, and successful projects very often attract “version 2” interest (and $) from consumers, especially the largest part of mass consumers who wisely adhere to the “stay away from version 1” philosophy. Just as those customers and potential customers were chomping at the bit for more…the Angular team unleashed the bombshell on the producers: “Remember that big learning curve you climbed? Forget that stuff, get ready for a new climb. And by the way have fun maintaining that great new project you just built.”
Such a decision belies the underlying support structure of Angular, and says a lot about Google itself. Fact is, Google == AdWords. Compared to that, everything else has been a sideshow, and they’ve barely made a dime off any of it. Angular falls into this category, which is both a boon and a curse. The boon is the freedom to innovate and incubate, without which, Angular would never have come into existence. The curse is that the direction of the product does not give much consideration to such mundane issues as backward compatibility, support of an installed base, respect and succor to early adopters, etc. Or at least, back in 2015 it did not. The business overlords must have stepped in at some point and reasoned with the mad scientists, because ultimately Google decided to support both versions of Angular, at least for now, and has apparently allocated an amount of resources sufficient to do that. Both threads have experienced a moderate flow of new releases. That does not change the fact that the future of Angular is in the Angular 2-and-later lineage, not in the renamed AngularJS (old Angular 1). But it does introduce a bifurcation of the Angular community, and of Google’s development resources, that was not planned or desired by anyone. It’s clearly a bandaid.
Developer Economics released results of a survey1 in early 2017 which indicated that, of the prominent Javascript frameworks, Angular 1, Angular 2, and React all had about 10% of developer interest (jQuery by itself was the elephant in the room, with about a third of all developers. But interest there of course seems to be gradually receding for various reasons, such as the monolithic nature of the library, the absence of a framework, etc.). This is an obvious, real problem for Angular when one realizes that, in light of the continuing, if slow, releases of Angular 1 in the second half of 2017, Angular is clearly competing not only with other frameworks, but with itself.
It didn’t help that the project to develop Angular 2 was a total mess. Over the course of about a year, it saw at least nine “release candidates,” almost all of which had a large number of breaking changes. In hindsight, the communication to the development community should have been “CAUTION! Geniuses at work…” But instead, the repeated message was “stick with us, we’re almost there,” and “this Release Candidate might be the one.” This for a year’s worth of release candidates??? Suffice to say, it was during this period that interest wavered, and React was the main beneficiary. In some ways React is almost the anti-Angular in its simplicity and ease of adoption. Of course, important pieces are left out (like for instance the back end), necessitating the knitting together of other libraries or frameworks to build a useful project, with all the complexity that brings. (Spoiler Alert: this in turn will spell React’s doom, as people blame it for not doing stuff it never intended to do in the first place. That’s probably an upcoming blog for about 2019).
Documentation for Angular 2+ also sucked for quite a while. It is only now that it is rounding into shape, helped by the afterthought, but highly valuable, AngularCLI project, which in the end was also delayed quite a bit (and which also distracted the core development team from Angular itself, while CLI 1.0 was being developed). The CLI oversimplifies Angular somewhat, but it provides a very solid intro point to the framework itself, giving development managers a much better chance to control project style and tempo in the real world. This stroke of genius might prove to be the salvation of Angular’s future, but alas it seems a valid assumption that the documentation took the biggest hit while the CLI was being incubated, quid pro quo.
The White Hats
The team responsible for Angular remains relatively stable, though the key influencers, Misko Hevery and perhaps even more importantly, Victor Savkin, have largely moved on. But Igor Minar and Tobias Bosch are still involved along with many other names who have 1+ years of contributor history, several of whom are listed as speakers for AngularMix in October 2017. This is not some fly-by-night open source effort whose key players will disappear in the night without fanfare. Clearly Google and Microsoft are happy to support the participation of these gifted engineers on both Angular and AngularJS, as well as the assistive technologies such as TypeScript and ReactiveX, which have general utility far beyond Angular.
More importantly, since version 2, releases have remained as scheduled, timeboxed for every six months. There was no Angular 3 (for an esoteric and valid reason), but this month marks three consecutive on-schedule releases (actually Angular 2 sort of randomly appeared when it was ready, but 4 appeared pretty much on schedule, and 5, though about a month late, seems ready to debut).
Angular 2 Material (controls based on Google’s Material Design) remains perennially in beta and it would be nice for it to get some love, just so the Angular crowd can claim “widgets? we have widgets.” There is rumor it will go GA with Angular 5, but the past has taught us that rumored release dates are not a good thing to go on in the Angular world. Angular 2 Material would make it easier for new developers to adopt Angular, but already what is there is worth a try, and anyway, it is not strictly necessary for Angular’s success. For those adopting Material Design, Angular 2 Material will definitely be a productivity enhancement, and it will bring some conformity, or at least commonality, to the look and feel of Angular apps.
So What To Do?
In short, I’d keep a watchful eye on Angular over the next year. If Google continues to stick with releases every six months, and if the project team stays together, it’s only going to get better. Facebook and Alibaba are simply not credible as tool builders. At least, not compared to Google, and especially not to the reborn Microsoft under Satya Nadella. In all this, Microsoft has been the bulwark of sanity, acting largely behind the scenes but seeming to put every babystep right, and clearly having the resources to do so. Microsoft is not married to Angular or to Google, but they are married to keeping a check on Apple and iOS. Angular provides a great opportunity to leverage ES2015 and beyond to make the browser experience as capable and high-quality as the native app experience, and it’s a safe bet that Microsoft is in it for the long run, so long as Apple keeps selling iPhones.
If you are starting a small-to-medium-sized project today and don’t have a vested interest in another framework, Angular 2 (via the CLI) is a worthy choice.
If you are starting a large project, you probably already have a stack, or are constrained by your available talent. If so, its probably not a great time for you to become your company’s Angular evangelist, at least not until the AngularJS / Angular bifurcation settles down. If not, give Angular 5 (again, via the CLI) a serious look. If your project team can handle it, it may well be a homerun.
In another year, if AngularJS continues to dominate the Angular job postings, stick a fork in the whole Angular enchilada. Besides, by then there will be some other shiny new framework to victimize you.
1 Developer Economics. State of the Developer Nation Q1 2017 (http://vmob.me/DE1Q17), p. 19
