Saturday, March 7th: I’ve been mostly sipping whisky (The Tennesee straight bourbon sort, not the proper Scotch sort! My stock of Scotch seem to have somehow magically depleted…) and watching presentation videos from ng-conf 2015, held on March 5th-6th in Salt Lake City, Utah in United States of America — so maybe my choice of whisky was appropriate?
The presentations mostly discussed the upcoming Angular version 2 and how the current Angular 1.x development accounts for that.
So here’s what I found most interesting in 2015 ng-conf:
Migration path!
Let’s start with the big one: Last year’s biggest rage in Angular community seemed to be about the announcement from Angular core contributors that there will not be a migration path from Angular v1 to Angular v2.
Luckily for us who are currently developing Angular v1 apps, Brad Green and Igor Minar told that there will be a migration path! The main component in migrating to version 2 will be the new router, which will work for both versions 1 & 2 of Angular and allow one to run both versions of Angular inside one app.
There are two ways to approach the migration:
- Inside-out: where the main application is still Angular 1 and parts of the application will be refactored for Angular 2
- Outside-in: where the main application is first refactored into Angular 2
Michał Gołębiowski and Andrew Joslin discussed the details of refactoring Angular 1.3 app to ES6 powered Angular 2 app and it didn’t look impossible!
About the new router
Brian Ford gave a good introduction to the new router that is slightly based on the community work of ui-router, but developed in TypeScript with Angular 2 and the migration path from 1 to 2 in mind.
The funny thing about the new router is that it actually has some EmberJS related code in it, from project called route-recognizer.
New Syntax
When I first saw the “bracket-attribute-based template syntax” (as I call it) of Angular 2 few months ago, I was disgusted:
That didn’t look really “HTMLy”. But, as Miško Hevery pointed out in the 2015 ng-conf Friday’s keynote: those “bracket-attributes” are completely valid HTML as syntax goes. Though they certainly are not global attributes and I noticed that W3C validator (which unfortunately is less and less useful tool these days) reports “Attribute [foo] is not serializable as XML 1.0.” error even if HTML5 validation is chosen.
There will also be a “canonical syntax” without the brackets with “bind-prop” and “on-event” attributes (which I suspect can be prefixed with “data-” to make them valid HTML5, though I have nothing to back that up).
Turns out this new bracket-attribute based syntax actually makes templates even more descriptive: Instead of using ng-bind attribute which will set its value to element’s text one can simply use [text] attribute or instead of ng-hide one can simple set attribute [hidden] to true (notice how these bracket attributes map to the standard HTML attributes).
Properties, events and methods
The Angular 2 DOM API consists of properties, events and methods:
- Square brackets [] signify expressions (used with properties)
- Parenthesis () signify statements (used with events)
- Hash mark # signify a rerefence (used with methods)
In Angular 1.x it is difficult to access another element’s methods in the template. In Angular 2.x a reference declared with a hash mark allows one to do just that:
A lot less of syntax
By introducing this new syntax Angular 2 does away with a lot of (now unnecessary) directives:
Tooling
Besides actually simplifying the Angular 2 DOM API for the developer, due to the new syntax, Angular 2 can for example catch typos in properties and I suspect that down the road editors/IDEs will take advantage of this new syntax as well.
Web Components & Shadow DOM
Angular 2 actually does not care if a DOM component is a native browser element, Angular component or Web Component. There is no difference and the API will be same to all components, so mixing them is not at all a problem. This is because Angular is retiring its transclusion feature used in Angular 1.x for “replacing an element” and uses instead standard Shadow DOM feature from Web Components. For browsers that do not support Shadow DOM Angular 2 will emulate/shim it.
Performance
AngularJS 1 can be pretty slow especially with long lists (at least without any optimizations). Here’s Dave Smith showcasing it in his performance related presentation:
As probably many others have done already, I’ve been looking into using ReactJS as way to boost up performance in Angular 1 apps, which is exactly what Dave showed, a much faster performance with AngularJS v1 + ReactJS:
But then right at the end of his presentation, he showed the same demo with Angular 2 and the result is more than impressive, almost instant! READ THE UPDATE BELOW!
UPDATE March 8th 8:57 PM UTC:
As few people have already notified me on Medium.com notes and on Facebook that there was a mistake in the above presentation by Dave Smith. The Angular 2 demo was set to zero millisecond timeout instead of the same 500ms timeout that the Angular 1 & ReactJS demo had, so the comparison above is false. Smith and ng-conf have uploaded a new video of the presentation where on the end Angular 1 & ReactJS vs Angular 2 are compared with the same timeout. You can see it here: http://youtu.be/XQM0K6YG18s?t=17m37sThe performance difference is now much smaller there and one has to note that Angular core contributors helped to optimize the Angular 2 demo, but ReactJS people haven’t had the change to optimize the Angular 1 & ReactJS demo.Turns out there is no silver bullet.
As Victor Savkin points out in his blog: “In Angular 2 there are no two-way data-bindings” (at least not at the moment). I guess that combined to the new reinvented change detection are probably the biggest reasons for these performance improvements.
Change detection graph in Angular 1.x was more like a “cycle” where for example it is sometimes unclear which nodes update in which order. In Angular 2 the change detection graph is a directed tree structure which is a lot faster to work with:
Types, Supersets and Future of JavaScript
Previously I have personally been strongly against types in JavaScript, but maybe it’s the fact that last few years I’ve been building more “enterprisey” JavaScript software for both browser and NodeJS, that has lately lead me to think that types in JavaScript might be a good idea. This “revelation” of mine happened at convenient time as Angular 2 seems to be about typed languages.
AtScript no more, just TypeScript
Maybe a bit controversially, when Angular team started developing Angular 2 they decided to use AtScript (created by Google) which actually was an extension providing annotions on top of Microsoft’s TypeScript which then is a superset of JavaScript adding optional static typing along with providing features of upcoming ES6 version of JavaScript. *Phew*
Luckily at ng-conf 2015 things got a little more simpler as the Angular core contributors together with the TypeScript team’s Jonathan Turner from Microsoft announced that TypeScript v1.5 will merge the annotations feature from AtScript and Angular 2 development will be done using it.
A lot of the talk in the conference was about TypeScript, the Angular core contributors kept reminding that even though Angular 2 itself is developed with TypeScript, one can still develop applications on top of Angular 2 with plain JavaScript.
Flow type vs TypeScript
Angular contributors Brad Green and Igor Minar mentioned that they’ve been discussing types in JavaScript with Facebook too, but they did not specify anything else.
Facebook has developed something a bit similar as AtScript/TypeScript, called Flow. But Flow seems to be more about “additional type checking for JavaScript” than “bringing types into JavaScript”, especially now after they introduced support for “Flow comments”: So I suspect that Flow with Flow comments will most certainly become a “lint-like” type checking tool for JavaScript developers that do not want an extra compilation step (like TypeScript to JavaScript) into their build process.
Future of JavaScript?
TypeScript with backing from Microsoft and Angular core team which sort of means “Google” combined with the growing interest from developers on bringing types to Javascript (which can be seen for example in the amount of contributors in DefinitelyTyped and general hype in the internet), it might not be so far fetched to say that we will have types in vanilla JavaScript in few years.
Actually there are some drafts regarding of bringing types into ES7 already. Also, in their welcoming keynote Brad Green and Igor Minar told that they want to take annotations and types from TypeScript and bring those to TC39 standardization process.
Summary
At first I didn’t like Angular 2 at all. Mostly because of the weird looking syntax and the announcement of “no migration path”. But:
- the new syntax seems to make more and more sense
- there is actually a migration path from v1 to v2
- the performance improvements almost seem to reach “Apple-esque superlatives”
… it seems that now I can’t wait for Angular 2 to become production ready! Hopefully towards the end of the year we’ll have something at least “almost production ready” to play with:
Disclaimer of sorts
Because I haven’t yet tried Angular 2 alpha myself (or because of the whisky), it is entirely possible that I’ve understood something a bit wrong, so if you spot anything, please leave a note!
