AngularJS, for me, was a revelation the first time I encountered it. I was coming from using GWT (Google Web Toolkit), and seeing our large application shrink in lines of code by 90% was close to a spiritual experience. I was a convert from day one, because I knew how bad things were otherwise. Ever since, I have been associated with AngularJS in one way or another, and have seen how it makes things absolutely simple with data binding, templating, routing, unit testing, and so much more. But the more I used it, some things didn’t make sense, from naming to concepts. I got the hang of it, but I never really got to like why directives needed to be so complex, or how the built-in routing was quite limiting. While AngularJS made it trivial to write applications, it also made it trivial to write slow, hard-to-maintain applications if you didn’t understand how it all worked together.
With each version of AngularJS, and with each improvement in documentation, things started improving for the better.
- Data binding performance improvements were made with each successive release.
- The AngularJS documentation underwent a major overhaul to make it easier to consume and understand.
- Routing became an optional module.
- The community created many modules and plugins to improve things, from localization / translation (angular-translate), to a better routing (ui-router) to whatever else you might ever need.
AngularJS has undergone significant changes under the covers from version 1.0 to 1.3 to improve almost every single part of AngularJS, visibly or otherwise. It has gone from an experimental MVC framework to a stable well-supported framework with significant adoption. I have done more workshops on AngularJS in the last year than I did in all the years before it, combined.
But the core AngularJS team (which has also grown) have not been sitting around resting on their laurels. After 1.3, instead of looking at incremental improvements, they decided to tackle what the team has been calling AngularJS 2.0. Taking into account feedback from developers, as well as inspiration from other brilliant frameworks out there, AngularJS 2.0 aims to be as revolutionary a step forward from AngularJS 1.0 as AngularJS was when it released. And unlike last time, the community has been involved significantly, with all the design docs available for review and comments. Here’s why you should be looking forward to AngularJS 2.0 (though of course, any and all of it might change by the time it releases).
Forward Looking
With AngularJS 1.3, AngularJS dropped support for IE8. AngularJS 2.0 looks to continue this trend, with the focus on faster, modern browsers (IE10/11, Chrome, Firefox, Opera & Safari) on the desktop, and Chrome on Android, iOS6+, Windows Phone 8+ & Firefox mobile. This allows the AngularJS codebase to be short and succinct (without needing hacks for older browsers), and also allows AngularJS to support the latest and greatest features without worrying about backward compatibility and polyfills. The expectation is that by the time AngularJS 2.0 rolls out, most of these browsers will be the standards and defaults, and developers can focus on building apps specifically for them.
ECMAScript 6 + Redux Dependency Injection
ECMAScript 6 is what JavaScript will be like in a few years: A truly object-oriented language with native JS class support, and first class module and AMD (Asynchronous Modular Dependencies), and tons of improvements to the syntax to allow for more concise, declarative code. The entire AngularJS 2.0 code will be written in ES6. But you might think, hey, none of the current browsers support all the ES6 features — what does that mean for me as a developer?
Have no worries. Even though the entire AngularJS source code will be written in ES6, it will compile into standard ES5 (or what we call Javascript today) using the Traceur compiler. AngularJS is also adding support for annotations and assertions into the Traceur compiler, so that the AngularJS application you write can be even more declarative, by just adding annotations instead of any crazy syntax (the current dependency injection system, anyone?). So you might be able to write AngularJS code like this very soon (not necessarily the final syntax though):
@Inject(CoffeeMaker, Microwave)
class Pantry {
constructor(coffeeMaker, microwave) {
this.coffeeMaker = coffeeMaker;
this.microwave = microwave;
}
makeCoffee(finishedCb) {
this.coffeeMaker.turnOn();
this.coffeeMaker.makeCoffee(finishedCb);
}
}
And AngularJS 2.0 will be fully backwards compatible with ES5 (it has to be), so you can continue writing an equivalent syntax without ever having to deal with ES6 syntax, if you so decide.
Faster, Buttery-smooth
Nowadays, Everything needs to be faster, faster, faster. 60 fps, load time of less than 400ms, and so on. With version 2.0, the focus is on speed. How fast can the UI be updated? How can the data binding be sped up? One approach is to replace the dirty checking that AngularJS currently does with Object.observe, which is a proposal to add native support for model change listeners and data binding. AngularJS 2.0 will totally use this to significantly speed up the whole data-binding and update cycle.
But Object.observe is still only supported in Chrome canaries, and no other browser. It seems like there is still quite some time before it makes it out as a default in all the browsers. Thankfully, the AngularJS folks have been hard at work on the change detection feature, and have some insights on how to improve the dirty checking for objects and arrays significantly without the need for Object.observe support in the browser. The aim is to be able to handle several thousands of bindings under 1 ms. The design doc lays out how AngularJS 2.0 plans to handle this.
Flexible Routing
Routing was a core AngularJS feature in version 1.0, and became an optional module (ngRoute) in version 1.2. Part of this was because of some excellent work done by the open source community to support a wide variety of requirements and needs, like child and sibling states. The UI-Router module stepped up and handled this beautifully, while providing a syntax similar to that of ngRoute.
With version 2.0, the aim is to bring in some of these features (nested states, sibling views) into the core AngularJS router. At the same time, there were multiple other requirements that were not easily satisfied with routing in AngularJS:
- State-based transitions: UI-Router supported this, but it was not part of the core AngularJS routing module. So sub-states, sibling states where different parts of the views corresponded to different states of the URL / application will be declaratively and simply specified as part of the routing in AngularJS 2.0.
-
Authentication and Authorization: This was done using resolves in AngularJS, but AngularJS 2.0 plans to introduce a common, easy to understand idiom to support authorization and authentication to be able to state requirements like:
- User needs to be logged in
- Only admins can access a certain page
- Only members of a certain group can navigate to the admin section
- Preserving State: In the current version of AngularJS, if the user quickly switches back and forth between two routes in the UI, the controller and views associated with those routes are destroyed and recreated every time. This might not be optimal for a variety of use cases. Thus, AngularJS 2.0 is exploring ways to preserve the state between such transitions (through an LRU cache or something similar), thus allowing state transitions to be faster and more optimal from an user’s perspective.
Data Persistence
One last major piece of the puzzle that is AngularJS 2.0 is the persistence story. AngularJS started with pure XHR request support (through $http and $resource). Sockets were introduced through third-party services and integrations. Offline support was done through LocalStorage on a per-application basis. These have become common enough in applications nowadays that rethinking the core AngularJS communication and persistence story was necessary. To this extent, the following are planned:
- Phase 1 of AngularJS 2.0 would come with support for Http communication (using ngHttp), Local Storage, Session Storage, and IndexedDB access (through ngStore), and WebSocket API (through ngWebSocket). Each of these would be optional modules that could be included on a per-project basis.
- Phase 2 would build on top of this to build offline-first applications, which would be able to check connectivity status, cache data offline, and more.
- Phase 3 would finally aim to build an ngData module which would allow developers to build Model classes which represent your data, and act as an abstraction layer on top of Phase 1 and Phase 2 modules. Thus, it would be able to handle offline access, querying network, fetching pages and so on.
The aim is to give developers the tools and the language to be able to declaratively create APIs and paradigms that reflect their data model and the way it is to be accessed, fetched and shown to the users. The ability to build offline-first or realtime multi-user presence applications should be possible with just the core AngularJS modules.
Summing Up
This article barely scratches the surface of the major revamp that AngularJS 2.0 promises or is attempting to deliver. We are still a few months away from even the very first unstable release of AngularJS 2.0, but the future is exciting for all developers.
Editor’s note: Get up to speed and find out what it takes to build structured web apps with “AngularJS: Up and Running” by Shyam Seshadri and Brad Green.
Public domain sextant illustration courtesy of Internet Archive.