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.
As someone who does a ton of mentoring and training in AngularJS, I have been watching the Angular 2.0 specification pages with some concern and interest. Many expat/current enterprise developers, myself included, saw Angular as a way out of the nightmare of pieced-together architectures in Javascript, and felt the syntax was easy enough for beginners to grasp, while the features such as controllers, filters, directives and services provided enough enterprise-like features to support good desktop development on the browser.
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
There is a new Google language (really a meta-language riding atop Javascript). AtScript – primer from Google; also good tl; dr article here – provides for data types and generics in variables, assertions, and other features not available in ES 5 (or even 6), that the Angular team is using to develop Angular 2.0. The language itself is extensible, so the Angular team has developed some extensions of their own. The Angular team seems to have written AtScript and moved away from Dart, which they used to build AngularDart earlier this year.
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
An alternate take on this situation is that Javascript is at a major crossroads with the ES 6 specification (FYI, ECMAScript is the JavaScript standard, so ES 6 = JavaScript 1.6). As JavaScript evolves, much as Java did from 1.4 to 1.5, new features become available and even desirable. As far as I understand, ES 6 does not break ES 5 code by default, just as Java 1.4 or even 1.1 code ran unimpeded in Java 1.5 and beyond. Keyboard cat will live on… And so will the Hampster Dance, I’m sure.
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…
The Javascript developer community seems destined to repeat many of the mistakes of many other generations of developers – bored with the status quo, they have to keep moving, even if keeping moving alienates developers who write code based on the fruits of their labors. It’s hard to ask your development manager for a cycle to upgrade a framework if the fixes are all because the new framework code broke your current codebase. So you’ll have lots of old Angular apps that are too expensive to upgrade.
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.)
Sure, the ES 6 factor is a huge one here. The biggest features of this version of the Javascript standard include modules, iterators, maps, sets, web components, annotations, and classes (see a good summary of the coming features here. Yes, classes. Something I really was glad to leave behind when I went to Javascript. It feels like a backlash from the language creators – “ok, we get it, everyone else has classes, so we should too.” Read “Execution in the Kingdom of Nouns” for a prescient look at where we’ve ended up lately, a world without too much ceremony in JavaScript. It’s kind of nice to have dynamic typing and easy object creation, you know?
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
But just because something is there, it doesn’t mean we should rush to use it. The Angular team is either making a correct move so far into the future that it’s hard for us to see it, or they’re making a bet on something other Javascript developers will ignore. Forgetting the compatibility concern – what do we do if we have old browsers to support that won’t move into ECMAScript 6 territory (they have a transpiler, Traceur, for that) – what if these features are poorly implemented across browsers? Why move there so quickly in a world where new browser features are frequently fraught with uneven support and bugs?
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.
Source Material
- 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
- Article on ES 6 as of August 2014 – what to expect from Javascript Harmony (ECMAScript 6)
- 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.
News coverage…
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.