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:
- Taking advantage of a crop of new web technologies.
- Fixing design flaws in Angular 1.x.
Both are very much worth doing. Let's look at each in turn.
ES6 is Coming
improvements over the currently version (ES5).
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.
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
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
sessions, Angular works best if the team makes a strong effort to stick with the following rules.
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.
Avoid the use of nested scopes. We have also stressed, together with many others, having controllers rely on “this” rather than on
$scope, 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 rangle.io, 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.