Our next article covering ng-conf 2015 discusses the first-day keynote. Overall, it contains the most high-level strategy of any of the sessions, and covers where Angular 1.x and 2.0 are going, as well as information about APIs such as the new router and animation libraries.
Paving the way forward – Angular 1 and 2
As we discussed back in December, Google has decided to develop a brand-new version of AngularJS, dubbed Angular 2.0, breaking backward compatibility. At the same time, they are continuing development of AngularJS 1.x, with the goal being to provide an upgrade path to Angular 2 over the next several major releases.
Angular 1.x – what's coming?
In the pipeline for March, we'll see an update to AngularJS – version 1.4.0 – which will have the following new features:
- Beginning of a refactored internationalization API (angular-i18n), which will allow for an
ng-messagetag that accepts expressions, and that can handle more complex translation strategies. - Refactored
ng-animateAPI - Better
ng-cookiesAPI – which now allows domain and path settings, and is no longer based on polling code so should perform better - 30% faster digest cycle times – this should help performance in applications where lots of data is being monitored and changed on the fly
- Compatibility with the new router API (
ng-new-router), paving the path to operating Angular 1.x and 2.x code side-by-side
Angular 2 – in alpha now
Angular 2.0 is in a very early alpha stage now. The code, launched on GitHub last year, is downloadable and you can build and run all of the benchmarks. A number of small demonstration GitHub repositories exist.
Angular 2 is optimized for performance in large-scale applications. It also uses a module system, which reduces any given component's load time and memory usage. It uses the Shadow DOM as a way to speed up page rendering, and does away with traditional two-way binding.
The codebase is being built using ECMAScript 6, and using the Angular team's AtScript annotations (I will be publishing a blog article on AtScript, TypeScript, and the cross-compilers shortly). It is then cross-compiled (with a process called transpiling) using the Traceur transpiler into ECMAScript 5 syntax.
The code is actually quite readable, even if the new ES6 syntax may be a bit confusing at first. This is because ES6 provides a very simple module system, which helps separate concerns, and using the class definition for Javascript objects is more terse than using the traditional constructor function and prototype syntax.
Developers can write Angular 2 applications using ECMAScript 5, ECMAScript 6, Dart, or using the Traceur compiler. It's really up to you what you want to code in, and you can always translate downward with the Traceur compiler to older browsers running in ECMAScript 5. How that works in reality we'll have to see, but I'll be experimenting a bit and will report on my progress soon.
I'd choose 4 directives to retire 34!
One side note about the new syntax and feature set is that the simplicity enabled removal of directives such as ng-enabled, ng-show, ng-click. A total of about 34 directives boiled down to 4, which makes working with the templates much easier!
Angular 2 – built continuously with benchmarks
The Angular team is very well aware of the common critique of Angular versus other frameworks – it does not scale linearly as apps get larger. This is mostly because of the amount of dirty checking the framework does when the digester is triggered, and the fact that the digester is cyclical. The team decided to do away with any cyclical approach, implement only one-way binding, and perform dirty checking in top-down (parent to child) fashion as one pass.
This is a vast improvement. Though some will miss the two-way binding features, most will opt to migrate to Angular 2 (and we're reasonably sure that the same types of things you're used to doing in Angular 1 will be provided in some fashion with Angular 2). But the huge advantage in migrating to 2 is the raw performance gains.
But the team needed a way to figure out whether their changes were actually leading to improved performance. They worked with Julie Ralph, creator of Protractor, to build a benchmarking tool. This is known as benchmark, and it is integrated into the Angular 2 repository. We'll see more about BenchPress in a future blog post.
The way forward – a new router?
If you want to know the things to focus on to get your code ready for 2.0, here is an (incomplete) short list:
- Begin using the
controllerAssyntax and storing your variables on the controller - Write modular code – keep your views and controllers together in subdirectories
- Use the new router
- Begin using ES6 and a transpiler to ES5, potentially the AtScript annotations
If you don't know about controllerAs check out the first article, or consult this excellent article by John Papa on the feature (he assigns the controller as vm on the page and aliases this to vm in the Javascript of the controller, thereby doing mostly what $scope does but with the constructor.
Curiously, John's article sample was used by the Angular team in the discussions of the new router for Angular 1 – they also had named their component vm in a sample.
So, what is the new Router, then?
ng-new-router – it's all new!
The new router was built with help from Rob Eisenberg see his video from ng-conf Europe. The current head of the team is Brian Ford, who gave us the rundown of the features, which we'll be covering in an upcoming article. But here is a quick rundown:
- You route to components – which in Angular 1.x will be
controllersandview templatespaired together. - Routing can affect various areas of the page. For example, one route change may modify three different areas on the page, named as
ng-viewportareas. You can have sibling and nested viewports. - All of the standard routing rules still exist, and you can pluck path and query string variables as before.
- The team will begin to consider advanced routing strategies, such as lazy loading, once the router initial release is done.
Exciting news, and though they are deprecating the old router, they are not removing it. So teams can take their time getting ready to move to this technology.
Using the router as the way forward
The new router functions as a bridge technology between Angular 1.x and 2.x by being the same API in both containers. You will be able to mount Angular 1.x as your outer application and host 2.x parts as they come online, or you will be able to start with an Angular 2 application, but host Angular 1.x code for compatibility.
Other APIs are being developed to support version 1 and 2 of Angular, so stay tuned. My money is on the team releasing several new 2.x compatible APIs each major 1.x release.
When do we retire Angular 1.x?
Remember how we discussed how 2.x isn't ready yet, and there isn't quite yet a migration guide? No problem. The team has committed to tracking usage of both platforms. They've launched a new website – angular.io, which will contain documentation of and host all new APIs and Angular 2 code, while the (angularjs.org)[http://angularjs.org] site will stay alive to support the 1.x efforts.
Google will use the traffic to both sites, GitHub repositories, message and bug areas to monitor how much each API is used. Eventually they will see when Angular 1 is no longer in major use, and will retire the development effort. But this is a clear signal that the team is listening, and will only end development of Angular 1 when the majority of the world has migrated to 2.x.
Pete Bacon Darwin has been brought on as the Angular 1.x project team lead. He is very well known to the Angular community and is committed to this approach of working within shared APIs as a way to migrate to Angular 2 while supporting Angular 1.
AtScript – Now a proposal and folded into TypeScript 1.5, Traceur
The AtScript additions to the TypeScript standard are officially being renamed as features of TypeScript 1.5, which is a transpiler that can generate ECMAScript 6 or ECMAScript 5 code. The team is also discussing these features with the TC39 committee (this committee steers the Javascript language future at ECMA).
For a particularly rolling conversation about this with Brendan Eich, Allen Wirfs-Brach, and others, see the meeting notes around as well as this take by Yehuda Katz on Decorators – discussion notes here.
My theory on why the Angular team pushed their annotations over to the TypeScript team and embedded in traceur was to preserve their codebase in case the TC39 committee decides in favor of decorators. If that happens, the development team will just flip their generators to convert code to ECMAScript compliant decorators instead of annotations. Or so goes my theory. I have a 50/50 chance at this stage of being right.
At any rate, the Traceur tool created by the V8 team supports these annotations for internal (Google) AngularJS framework development (as well as for Angular developers on the outside), and soon TypeScript will support both these features and most of ECMAScript 6. Stay tuned, it promises to be one wild ride in the build tools space (and if you are curious now, go look at Babel (nee 6to5) or Traceur or TypeScript). We did see demos of TypeScript doing code fill-in and refactoring within, of all tools, Sublime Text. So looking forward to this!
Angular Dart – now just an output of the Angular core team
If you experimented with Angular on Dart, you'd find that it was kind of its own island. The team realized that, and converted the code over to be written in ES 6, and uses Traceur to transform the code to Dart. Now, most of the team that wrote Dart Angular is folded into the larger team, thereby improving team velocity and reducing code duplication.
Coming up next…
My next report will be about the new Angular Router. We’ll look into why it is better than the existing router, and how you can use it to provide multiple view areas, componentize your code, and get ready for hosting Angular 2 components within an Angular 1 application.