AngularJS has taken the world by storm. No one can deny that. Angular’s declarative method allows developers and designers to work together, designers producing the designs and design of the pages with pure HTML and CSS, and developers adding the functionality of the page with instructions.
With each version of AngularJS, and with each improvement in documentation, things started enhancing for the better.
- Data binding performance enhancements were made with each successive release.
- The AngularJS documentation underwent a major overhaul making it simpler to take in and comprehend.
- Routing became an optional module.
- The community created lots of modules and plugins to improve things, from localization/ translation (angular-translate), to a much better routing (UI-router) to whatever else you may ever need.
AngularJS has undergone significant modifications under the covers from version 1.0 to 1.3 to enhance almost each and 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.
However the core AngularJS team (which has also grown) have actually not been relaxing resting on their laurels. After 1.3, instead of looking at incremental enhancements, they chose to tackle what the team has been calling AngularJS 2.0. Taking into account feedback from developers, along with inspiration from other dazzling frameworks out there, AngularJS 2.0 aims to be as advanced an advance 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 remarks.
Forward Looking
With AngularJS 1.3, AngularJS dropped support for IE8. AngularJS 2.0 aims to continue this trend, with the focus on quicker, 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 brief and concise (without requiring hacks for older browsers), and also allows AngularJS to support the latest and biggest improvements without stressing over backward compatibility and polyfills. The expectation is that by the time AngularJS 2.0 rolls out, the majority of these browsers will be the requirements 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 lots of improvements to the syntax to enable more concise, declarative code. The whole AngularJS 2.0 code will be written in ES6. However you might think that none of the current browsers support all the ES6, so what does that mean for a developer?
Have no concerns. Even though the entire AngularJS source code will be written in ES6, it will compile into basic 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 comments instead of any crazy syntax. And AngularJS 2.0 will be totally backwards compatible with ES5 (it has to be), so you can continue composing a comparable syntax without ever having to handle ES6 syntax, if you so decide.
Faster, Buttery-smooth
Nowadays, Everything has to be much faster, faster, much faster. 60 fps, load time of less than 400ms, and so on. With version 2.0, the focus is on speed. How quick can the UI be updated? How can the data binding be sped up? One strategy is to change the unclean checking that AngularJS currently does with Object.observe, which is a proposal to include native support for model change listeners and data binding. AngularJS 2.0 will entirely use this to significantly accelerate the entire data-binding and update cycle.
However Object.observe is still only supported in Chrome canaries, and no other browser. It appears like there is still fairly a long time prior to it makes it out as a default in all the browsers. Thankfully, the AngularJS folks have actually been hard at work on the modification detection feature, and have some understandings on ways to enhance the unclean checking for items and ranges significantly without the need for Object.observe support in the browser. The objective is to be able to manage numerous countless 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 variety of requirements and requirements, like child and sibling states. The UI-Router module stepped up and managed this perfectly, while offering a syntax similar to that of ngRoute.
With version 2.0, the goal is to generate some of these features (nested states, sibling views) into the core AngularJS router. At the same time, there were several other requirements that were not quickly pleased with routing in AngularJS:
State-based shifts: UI-Router supported this, however it was not part of the core AngularJS routing module. So sub-states, sibling states where various 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 fixes 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 specific page
- Only members of a particular group can navigate to the admin section
Maintaining State: In the current version of AngularJS, if the user rapidly changes backward and forward in between 2 routes in the UI, the controller and views related to those paths are damaged and recreated each time. This may not be optimum for a range of use cases. Hence, AngularJS 2.0 is exploring methods to protect the state between such transitions (through an LRU cache or something comparable), therefore allowing state transitions to be much faster and more ideal from an user’s viewpoint.
Data Persistence
One last significant piece of the puzzle that is AngularJS 2.0 is the persistence story. AngularJS started with pure XHR demand support (through $http and $resource). Sockets were introduced through third-party services and combinations. Offline support was done through LocalStorage on a per-application basis. These have ended up being typical enough in applications nowadays that rethinking the core AngularJS communication and persistence story was needed. To this extent, the following are planned:
- Stage 1 of AngularJS 2.0 would come with support for Http communication (using ngHttp), Local Storage, Session Storage, and IndexedDB gain access to (through ngStore), and WebSocket API (through ngWebSocket). Each of these would be optional modules that could be consisted of on a per-project basis.
- Stage 2 would improve top of this to build offline-first applications, which would have the ability to inspect connectivity status, cache data offline, and more.
- Stage 3 would finally aim to build an ngData module which would permit developers to build Model classes which represent your data, and function as an abstraction layer on top of Phase 1 and Phase 2 modules. Thus, it would be able to handle offline access, inquiring network, fetching pages and so on.
The goal is to offer developers the tools and the language to be able to declaratively create APIs and paradigms that reflect their data model and the method it is to be accessed, brought and revealed to the users. The capability to build offline-first or realtime multi-user presence applications need to be possible with just the core AngularJS modules.
Source: http://radar.oreilly.com/
