All the talk of Angular 2.0 at ng-europe at the end of October has left a lot of folks worried about the prospect of a revolutionary change. Indeed, Angular 2.0 presents a major departure from Angular 1.2 and Angular 1.3. Gone are 1.x style controllers and $scope. No more jqLite. Directives, now known as “components,” are barely recognizable. Angular’s module system is getting dropped in favour of ES6 modules. Dependency injection looks very different. And, to top it off, AngularJS team is introducing a new dialect of JavaScript: AtScript. It’s easy to see why some are worried whether those who bet on Angular 1.x today might be end up having to do a complete rewrite of their apps in a year or two.

For those who are worried, here is a more happy take on the upcoming changes.

To make sense of those transition, we need to consider that most of the proposed changes in Angular 2.0 are motivated by one of two things:

  1. Taking advantage of a crop of new web technologies.
  2. Fixing design flaws in Angular 1.x.

Both are very much worth doing. Let's look at each in turn.

ES6 is Coming

Regardless of the strategy pursued by AngularJS, the foundational front-end technologies will be transformed in the next few years. One major change is the introduction of EcmaScript 6. ES6 is a new version of JavaScript, which offers a large number of
improvements over the currently version (ES5).

There is a cost of those improvements: many JavaScript developers will be looking at what may almost seem like a new programming language. It will most certainly be a better language, though, so this cost will be well worth it. As far as we are concerned, it’s just a matter of waiting for browser and transpiler support to become sufficiently solid.

You'll Want an ES6-based Framework

The transition to ES6 introduces a challenge to all existing frameworks. When using ES6 becomes practical, frameworks that take advantage of its features (such as classes and “native” modules) would look a lot more attractive than those that do not. Angular 2.0 is AngularJS’s team response to that challenge. It is a framework that is based on ES6 and that aims to take advantage of the new features introduced in ES6. A large part of the reason Angular 2.0 looks so different is precisely that it makes use of those new features. Other frameworks that compete with Angular 1.x today will also look quite different once they leave ES5 behind.

It is worth noting here, a good deal of Angular 1.3 is a polyfill for the missing features of today's JavaScript. This will no longer be necessary when such features become available in JavaScript.

But Will it Happen?

Angular 2.0 is a bet that ES6 will happen sooner rather than later. Let’s note, though, that the transition in ES6 is largely in Google’s hands, since it depends on two things: solid native support for ES6 in Chrome and really solid support of all other browsers via traceur. Once both are available, real-world use of ES6 becomes possible. Chrome and traceur are both Google projects. If they feel confident that those tools will be ready for real-world use soon, a big bet on ES6 in Angular 2.0 makes a lot of sense.

AtScript is an ES6 Upgrade

The timing of Google’s new “AtScript” dialect of JavaScript is also easy to understand considering the transition to ES6. AtScript looks quite different from ES5, but its difference from ES6 is minimal. More importantly, the Angular team might be hoping that developers who are eating the cost of switching from ES5 to ES6 could be easily convinced to take the “upgrade” and go with AtScript while they are at it. For a few years we will all be transpiling our ES6 code using a tool like traceur in order to accommodate browsers that don't have native support for ES6. Transpiling AtScript might not be all that different. (It’s worth noting, of course, that one does not need to use AtScript to work with Angular 2.0.)

Don't Forget Web Components, Etc.

ES6 is just one of a number of changes coming to front-end development independent of AngularJS. Another major one is Web Components. As with ES6,
frameworks that fit well with Web Components will fare better once Web Components are in common use. Some of the changes to Angular 2.0 aim to further bridge the gap with Web Components.

Dropping Parts No One Should Miss

As AngularJS 1.2 grew in popularity, it became clear that some of the features of the framework do not scale well. This is not a fault of AngularJS, but rather the result of the AngularJS community learning what works and what doesn’t. After all, AngularJS has been subjected to real world scrutiny well beyond that experienced by other frameworks.

As we have stressed in our own training
, Angular works best if the team makes a strong effort to stick with the following rules.

  1. Put as much code in services as humanely possible. Our mantra has long been: “Code that can be written without referring to a controller's scope should be written this way and should be places in a service.” Controllers and directives should be reduced to the minimum, only handling UI concerns. They should handoff work to services at the earliest opportunity. Services should be small and strive to limit the number of dependencies.

  2. Avoid the use of nested scopes. We have also stressed, together with many others, having controllers rely on “this” rather than on
    , ideally eliminating the use of $scope altogether. This way controllers can mind their own business and not reach out into other controller’s data via scope inheritance. (Getting other controller’s data via scope inheritance looks convenient at first, but becomes a nightmare in a more complex application.) Similarly, we have argued that directives should use isolated scope. Controllers and directives should avoid communicating except through services.

(RIP Image from AngularJS Team Talk at ngEurope)

In this context, hearing about the demise of controllers and $scope in Angular 2.0, we can’t help but say: “Good riddance!” Needless to say, there is a cost to such a change. Transition to ES6, however, seems like about the best time to eat up this cost.

Will It Hurt?

Teams whose approach to AngularJS has stressed services will find the transition to Angular 2.0 a lot less daunting, than those who have put all of their code into controllers or non-isolated directives. Angular’s services are fairly simple in their design. Retrofitting Angular 1.2 services to be usable with Angular 2.0 should be quite feasible even if Angular team does not make a strong effort to offer a migration path (though I am sure they will). Such retrofitting would be further simplified if your services are small and prudent when it comes to picking dependencies. And, of course, this is a strategy worth pursuing regardless of what Angular 2.0 might look like at the end of the day.

Future Proof Architecture for AngularJS

Looming Angular 2.0 provides a good reminder of the need to think about long-term maintenance of applications built on the evolving foundation of the Web. As we move more and more functionality to the browser, we end up with potentially hundreds of thousands of lines of client code. Being able to leverage this code for years becomes crucial. Regardless of what Angular 2.0 ends up looking like, eventually you will need to upgrade your code to the next framework du jour. How will you handle this transition? At, we've been tossing this question around for a while and we are now preparing a white paper containing our recommendations for developing “future proof” applications using AngularJS 1.3. Stay tuned for more, meanwhile please share your thoughts.