With the imminent release of Angular 2 and the recent announcements from ng-conf 2016, the World Wide Web is abuzz with news regarding the next big thing. While scepticism was reserved for their initial communication about Angular 2, the team at Google has managed to dispel even the hardest cynic’s concerns. Most of the initial dialog about Angular 2 has revolved around its relationship with TypeScript, and its drastic departure from the Model-View-Controller metaphor, but there is so much more to the reinvented framework than that.
Working with Microsoft to evolve TypeScript, the changes have allowed the team to greatly simplify the design of an Angular application and separate the concerns of configuration and behaviour. Additionally, the architecture of an Angular 2 application aligns closely with the W3C’s web-component strategy, with the forced Model-View-Controller metaphor having been abandoned. The new component based architecture is much cleaner, and allows applications to easily scale in complexity. Everything is a plain TypeScript class with well-defined annotations and clear extension points.
Much effort is being invested in scaffolding and build tooling in the form of the new Angular 2 command line interface. While still in active development, it aims to simplify the access to features currently offered by a variety of disparate tools – such as Grunt, Gulp, and Yeoman. The real value, however, comes in the form of the debugger tool; Augury. Developed by the team that built Batarangle and Angular 1.x visualizer, Augury is a Chrome plugin that provides deep visualisation of component tree, dependency graph, router configuration, scope variables and much more.
One of the biggest criticisms that the team has had to confront is the performance. Angular 1.x is slow, very slow. An acute awareness of performance is at the heart of Angular 2 and it has necessitated a fundamental redesign of their change detection model. The Angular team embraced a flux-like unidirectional propagation of data by separating the event and property binding into 2 separate flows. This means that the propagation of changes through the component hierarchy is much more controlled, isolated and any changes in any component scope won’t result in a full digesting of the page – an unintended side effect of some prevalent patterns in Angular 1.x. All told, the Angular team is reporting a fivefold improvement in rendering performance over Angular 1.x, as well as a reduction in framework payload size from 56kb down to 45kb. Many more features, executing faster with a smaller footprint.
While the performance is greatly improved, it still has the fundamental problem of any single page application (SPA), the time of the initial page impression is awful. Research from Google AdSense indicates that on the open web, a difference of 200ms on a page load can fundamentally alter the user’s perception of and interaction with an entire site. To address this the Angular team has created an isomorphic renderer for Angular 2, allowing it to render Angular templates independently of the browser – on the server. This allows for static html files to be generated at build time and deployed in conjunction with your application, quickly served as a first impression to the browser, while downloading the full application in the background. Angular 2 then has a preboot function that records user interactions, and ‘replays’ the sequence of events internally once the application has fully loaded. While this whole process should ideally all be sub second, leaving the user with the perception of amazing performance.
What does Angular 2 mean for BBD?
• Component-based design means that the solutions will scale better with complexity
• Great performance means that the framework can scale up to any of our solutions, with fewer performance pitfalls.
• TypeScript means that it will be easier for developers with C# and Java skill to bridge the gap to the front end.
• TypeScript will allow our applications to be future-proofed to a far greater degree than they are at the moment.
• Better tooling means it’s easier and faster to find and fix bugs
• Cross-platform development with a high degree of code reuse, and without needing a new skill set, all while still running natively
It’s in release candidate at the moment, we should be able to start using it in production later this year.