Update – 11/18/2014 – I ran across this letter to the Angular team announcing Pete Bacon Darwin is to head the Angular 1.x effort going forward. This is a very good sign that the Angular developer community heard and recognizes the concern about the longevity of the 1.x branch. Stay tuned for more information and another article shortly.
Onward to 2.0?
But then Angular 2.0 was hatched, as a project to re-engineer the framework from the ground up. If you follow the specs, you’ll see a lot of new syntax, new ideas, and focus on making the syntax less ambiguous. Some of this will be quite welcomed by developers, and the team should be given huge credit for building their specifications in the public eye, and accepting criticism and comments from the community well before the next generation architecture is dropped on them.
What is the controversy?
Although Angular will run on ES 5 browsers (the current world), changes being made to the core Angular architecture will break every Angular application. See this InfoQ article for details, which include removal of controllers, current directive definition syntax, $scope, and more.
A number of bloggers and forum post commenters (which may or may not be consensus depending on the percentage who are writing who are in the opposite opinion) are quite upset. Confirmation bias and gut reaction of course are at play here to some degree, but there is a groundswell of commentary and concern around the fact that there is no plan at backward compatability.
AtScript – a new language for Angular Framework development
For the uninitiated, AtScript is processed by the Traceur compiler – really good overview of ES6 and Traceur in this presentation from ng-conf, which takes ES6 (and additional AtScript language extensions syntax) and spits out ECMAScript 1.5 code. This is a very interesting language, and it seems to be replacing features of Angular with either native ES 6 features without Traceur, or with Traceur, ES 5 shims.
I’ve been seeing posts and replies by developers and development managers asking why Google wants to change to such a degree that their code immediately becomes legacy once 2.0 becomes the main development line.
The thing that riled many is embeded in this AngularJS team post after ng-conf Europe:
Our goal with Angular 2 is to make the best possible set of tools for building web apps not constrained by maintaining backwards compatibility with existing APIs. Once we have an initial version of Angular 2, we’ll start to work on a migration path for Angular 1 apps.
That is a goal you commonly see when a development team decides that it is not worth the trouble to enhance the current platform, so a rewrite is the only choice. I don’t get the sense the majority of the end-developer community shares this feeling. Sure, things like directives have to be broken down into simpler components or at least become easier to test, but throwing the entire API out and starting fresh is a luxury – something you don’t want to visit on the large community of developers who have just adopted your framework and have a degree of zeal for using it in anger.
The long view… ES 6 is transformative too
Enterprise Developers don’t move that fast!
Some of the reaction comes from the needs of the enterprise itself. Not every enterprise application is ephemeral – some last for a decade (believe it or not). Some are internal, never see the light of day, and won’t need constant updates to their technology stack.
There are enterprise developers looking at writing phone-based apps with tools like Cordova (nee PhoneGap) and the Angular-based Ionic framework, so that their mobile sales force, marketing team, and others can work in the field, and they have an almost zero deployment footprint. Why break all of that code as well? Even if Ionic changes to meet the new features of Angular 2.0, won’t all Ionic applications suffer a re-write fate?
Deeper Dive – Rob Eisenberg’s blog post about Angular 2.0
After publication, I was sent a link to a fantastic All about Angular 2.0 (including controversy and current state / debates) blog post from Rob Eisenberg (of Durandal fame and an AngularJS 2.0 committer). For deep techies, this is essential reading.
History can repeat itself…
How Enterprise Developers Upgrade…
Remember Java? Well, it’s still out there. It’s actually everywhere. It’s not going away. If it is, usually it’s replaced by a JVM-based language like Scala, Groovy, JRuby, or others, but still running on the VM. Sure, there are pure Rails applications and NodeJS has made great inroads, but many of the enterprise developers who adopted AngularJS will wait until they know these platforms will stick around before they push for adoption in large organizations. And now Angular is in that mix of platforms where long-term stability is called into question by some.
I’ve been on all sorts of projects – in-house, short-term efforts, prototypes and startup web applications, and enterprise back-office support applications. Some of them need to live for a decade, some only need to live for 6 months. There is a time to use software that is good enough for the purpose at hand, without regard for the future of the stack, but for many projects, the software well outlives what the original developers had planned.
A call for a well-planned upgrade path
Google is stating that they will support Angular 1.3.x for about 24 months once Angular 2.0 goes to production. So we’re talking mabye three years time or so, and depending on the fallout from the backlash, maybe even more. The track record of supporting APIs and platforms at Google is mixed – Android is very successful and has been for years, with reasonable upgrade paths (because in part, it’s written in Java), but there are other APIs and platforms that have died.
Angular has huge adoption and fervent support from the community. It gets developers excited. From the get-go, the developers wrote a framework that focused on developer productivity, on simplicity and clearness in how things get done, and on test-ability. Yes, it can be difficult to learn at first, and there is that famous graph of developer satisfaction with adopting Angular that kind of sums it up. (credit to Lukas Reubbelkke for finding that one and sharing it! – he’s an excellent developer advocate for using Angular and his take on this is also very measured and has some very good points.)
So, let’s hope that the Angular development team moves a bit more methodically for an upgrade path. Supposing they allow Angular 1.3 syntax in the first major release line of 2.x – 2.0.x – and deprecate it for 2.1? That way, developers could ease into the new syntax and try new features, but could gradually upgrade their code to 2.x and pull the plug on the old code later in the game.
The bright and shiny
In short – take stock and tell us your new plans
I don’t think the team was quite ready for the backlash, but I hope they hear it, and at bare minimum make sure that Angular 2.0 applications can run Angular 1.x code without breaking it, or at least with a simple migration path. To do any less would be a big mis-step in my opinion (though others at Chariot may disagree with me, maybe even vehemently).
Even Java EE was able to pull itself out of the morass, and become a relatively decent application development platform. Spring is still going strong, even if it’s not “cool” – because you can upgrade it and nothing breaks. Java itself just finally got a semblance of closures with their Lambdas, which really embraces legacy code by giving it an upgrade path (anybody have single-method interfaces out there? Replace ‘em with a Lambda!).
Above all, it’s best to wait and observe…
My perspective here is this – don’t panic! There is no reason to throw out a highly productive SPA framework just because they are thinking big for their next release. The specs are not finalized, and there is a lot of discussion that was spurred by the presentation, including a deep debate on GitHub for the templating language, where the whole core team is involved.
Let’s hope the Angular team picks up on the concern in the community and embraces it. I look forward to watching how this plays out.
- Igor Minar and Tobias Bosch at ng-europe 2014 – covers Angular 2.0 syntax and goals.
- Misko Hevery on AtScript and Angular 2.0 at ng-europe – learn why they created AtScript and what it tries to solve
- All about Angular 2.0 by Rob Eisenberg
- The Traceur cross-compiler – the tool that compiles / “transpiles” AtScript into valid ES 6 code
- AtScript primer – A team-written tutorial on the AtScript syntax
- The Angular 2.0 specs folder on Google Drive – read here to see what the team is planning and proposing
- The AtScript playground project – very cool preview of the future. You need NodeJS, NPM, Gulp.
Positive-leaning 2.0 Opinion Posts
- O’Reilly Radar’s piece on 2.0 which it has to be said, was released a full month before ng-europe.
Reactions / Reflective posts
- Michael Bromley’s coverage of ng-europe and the keynotes.
- Lukas Reubbelke’s piece on keeping a level head while waiting for the team to come up with 2.0.
- It’s too soon to panic on AngularJS 2.0 – referenced by Lukas above.
- Dan Wahlin’s thoughts on Angular 1.3 -> 2.0
It’s best to remain circumspect… Much of the content out there seems to be highly reactionary and FUD-bait. I wouldn’t bother with the Hacker News or Reddit posts just yet, as they seem to mostly focus on frustration and on the fact that the change is happening…
We’ll keep tracking Angular 2.0 and these changes and keep you informed. But for now, nothing here suggests to me that current or even new projects should abandon Angular for anything else. First of all, the Angular team has made a commitment to the community (watch the videos, you’ll see how visionary they are), and unlike the backend, browsers are a world that constantly update and change, so expecting the same web application to run the exact same way for 10 years is just not practical.