Angular 2

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.

Angular 2 bears little resemblance to its forebearer. The Angular 2 team initially made a splash with their decision to embrace TypeScript rather than vanilla JavaScript, believing that a change to better tooling was necessary to take the framework forward. While TypeScript is a strongly-typed superset of ECMAScript 2015, and compiles down to plain old JavaScript, it appears very different to the de-facto style code of 2014.

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.

Another element gained by the move to the isomorphic renderer is that an Angular 2 application can now run without a browser window. Far from being a side-note, this divorce has meant amazing things for frameworks such as NativeScript and React Native. You can now write a native Android or iOS application in JavaScript and Angular 2, without it running in a sandboxed web view. It not only allows greater accessibility to cross-device development, but also allows for direct code sharing between your mobile and web applications. The same component code can be used on web and mobile – one being rendered by the browser using HTML and CSS and the other using the native UI renderers for the platform. This kind of widespread, cross-platform reuse is the holy-grail of our generation.

Finally, the team at Google is trying to coexist with the broader JavaScript community; working closely with other big players on the web, such as Microsoft, React and Meteor, to integrate with a vibrant and healthy ecosystem rather than stand apart. The ambition for Angular 2 is not just to be a framework, but to become a platform unto itself.

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.