The State of Angular 2.0: Are we there yet?

by
Tags: , , , ,
Category:

Note: Don Coleman and Andrea O.K. Wright contributed suggestions and reserarch for this article.

At Chariot, we've been tracking the replacement of AngularJS with a from-the-bottom-up rewrite called Angular 2 for over a year and a half now. This article tracks the changes to the framework and its related APIs as it enters release candidate phase.

We’ve tracked the progress here at Chariot via attending two conferences ng-conf 2015 and ng-conf 2016, an online conference Angular Remote Conf, an emerging training course, an IoT app we demonstrated at SxSW, Northeast Scala and at own Philly Emerging Tech conference, and lots of research, blog posts and conversations on Gitter. Each time we learned something new we tried to discuss what we found.

Preamble: 2015 alpha and beta releases

In the beginning of the process, just after ng-conf 2015, there were the initial alpha and beta periods. Angular 2 Project Manager Brad Green presented in the Day 1 keynote at ng-conf that we’d have all of the features we’d come to love in Angular 1:

[IGOR MINAR]Are all the features I still like in Angular still there?
[BRAD GREEN] So while the syntax and semantics have changed a bit from Angular 1, you’re going to find, I think, all the things that you grew to know and love about Angular 1 already in Angular 2…
Source: 2015 Day 1 Keynote

There was a flurry of activity before and after the conference that year where the team produced a line-in-the-sand public alpha, #27, and then thereafter continued over the summer, fall and winter to produce an additional twenty-seven alphas and seventeen betas.

During that time, the Angular 2 framework underwent some significant improvements and breaking changes, but in each progressive month we saw more and more of the core product stabilize and become real.

At Chariot, we invested some time writing a websocket-based graphing IoT application for our booth at South-by-Southwest with a late beta somewhere around beta 7 or 8. That application used Angular 2 and WebSockets with RxJs to power a distributed charting program, and though we had some interesting issues around change detection and the routing system, the framework proved to be relatively stable over the winter / early spring.

We found the combination of Microsoft's Reactive JavaScript and Angular 2 to be a powerful combination that made composing data from streams and showing them in UI components relatively painless. We didn't focus on forms and we jettisoned our use of the original Router, as it proved somewhat unstable for us. But much of the Angular 2 beta was solid.

Pre-conference: prep for and delivery of first RCs

Just before ng-conf 2016 in May of 2016, the last beta was released on April 28th. This beta introduced a change in the template API that was minor, but breaking: 

<li *ngFor="#item of items">{{ item }}</li>

became

<li *ngFor="let item of items">{{ items }}</li>

I missed that entirely as I was waiting on the RC. Several days later the first (and rapidly second, the longer lived RC1 release candidates were delivered, on the starting day of the conference. In RC0 and 1, there were some significant additions to the APIs, but they also included some changes that caused us to sit up and take notice:

  • The team renamed the monolithic 'angular' deliverable to @angular/core, @angular/common, @angular/compiler, etc… This was just before the conference started and caught people who weren't looking at the commits by surprise. The changes for this are in the RC0 release notes and the documentation in the Angular team’s Tour of Heros tutorial and the other docs were updated, but it did slightly break all prior examples.
  • The team deprecated their Router API, which had stagnated, and changed the import to @angular/router-deprecated.
  • The team released a new router, led by Angular creator Misko Hevery, named @angular/router, which they then announced at the conference would be the replacement for the existing router. Misko gave a presentation outlining it and discussing the features with the audience at the conference.

We and others scrambled to keep abreast of the changes and update our tutorials and samples. At Chariot, our team was building an Angular 2.0 training course assuming the features, once announced at RC, were ready to be put into slide and sample code form.

Though these changes were a bit concerning, we felt that they were the last major changes meant to stabilize what was "in" the RC code base and that this would be the start of real stablization before release. At Chariot, we started finalizing our Angular 2 training course and updated our blog articles to the new syntaxes and APIs. We held off on any documentation on the new router, however, since it was newly written and not proven yet.

The pause before the storm

Since the RC 1 release on May 3, 2016, the release train had gotten concerningly quiet. The Angular 2 team normally released betas and alphas every 1-2 weeks, and so it became apparent after the beginning of June that something big was coming.

We completed the major chapters of our Angular 2 Fundamentals Training course based on RC1 and delivered an internal run last week. During that time, we started discovering some of the features that weren't well documented or were half finished, such as some of the advanced testing APIs, and the differences in the model-driven and template-driven forms. We noted this in the training and planned on updating once the next RC came out.

We were about to find out that the second release candidate significantly moved the goal posts yet again.

The changes in RC2 and RC3: significant in scope and meaning

RC2 brought further changes to what was supposed to be a release candidate. The team pushed that release out and then a week later released RC3, so they are back to the weekly release process. By now it has been widely discussed that the Release Candidate label was probably applied too early. This next pair of RCs proved that point with the following changes:

Changes to Routing

The "new" router had become deprecated itself, so that:

  • The prior deprecated router had its last release on @angular/router-deprecated as version 2.0.0-RC.2. There was talk in the Gitter chatroom that they would rename it to @angular/router-deprecated-deprecated but that seems to have been resolved by just stopping any new releases.
  • There was talk that the new router became the new deprecated router, @angular/router-deprecated. However, this never came to pass. It looks like the router developed for ng-conf 2016 has been silently dropped.
  • Finally, a new router API was created, however it's not going to be released with the 2.0.0 package: officially delivered as @angular/router in RC3, it's currently stored on GitHub with the name Vladivostok, and is the work of the team at ngrx, a separate development team that created a Redux-like store called @ngrx/store and had a router in the works called @ngrx/router.

Forms API changes

The forms API changed as well. At ng-conf 2016, there was a presentation by Deborah Kurata, It’s just a TextBox, what could go wrong? Angular 2 Forms and Validation explaining how to use both template and model-driven forms. There was no hint of changes to come, at least not that the speaker discussed.

However, on June 3rd, over a week before RC2, the Angular 2 team released a design document – Forms Upcoming Change Proposal. In this document they outlined the new API’s breaking changes and a timeline.

First, RC2 would implement a new forms API as an opt-in optional package, and the existing forms API would require no changes. In actuality the forms API moved to a deprecated import and we found at least one breaking change.

Next, RC3 would require developers to opt in to either the new or deprecated forms APIs.

  • Rename @angular/forms to @angular/forms-deprecated.
  • Put a new forms API in @angular/forms but mark all of the classes with the @experimental tag.
  • Suggest developers who want the old forms API change their imports. This is not a straightforward change as we’ll see below.
  • The team suggests developers who want to try the new forms API and provide feedback call several functions to disable the old forms API and enable the new one.

Deprecated forms API: how to get it back for now…

While you’re waiting for the new forms API to stabilize, you can migrate yourself back to the old forms API. It’s still in the @angular/common package, but it’s been unexported and moved around. Here is what we did for our samples. Change from:

import {Control, ControlGroup,
        FormBuilder, Validators,
        FORM_DIRECTIVES} from '@angular/common';
import {ValidatorFn} from
       '@angular/common/src/forms/directives/validators';

to:

import {Control, ControlGroup}
   from '@angular/common/src/forms-deprecated/model';
import {FormBuilder, Validators, FORM_DIRECTIVES}
   from '@angular/common/src/forms-deprecated';
import {ValidatorFn}
       from '@angular/common/src/
             forms-deprecated/directives/validators';

If you’re using your own custom validator, the signature cannot have a returned ValidatorFn in it. We had:

fontNameValidator(validFonts: string[]): ValidatorFn

this became:

fontNameValidator(validFonts: string[])

as we omitted the return type. Using ValidatorFn as a return type directly worked in RC1 but is invalid in RC2. Victor Savkin noted that this was made accessible by accident in the comments for issue #8834.

Of course, if you’re on the sidelines, now is not the time to dive into development of a forms-heavy application. We would suggest experimenting and/or waiting until they stabilize the API.

Case Study: Changes to the Angular Material 2 Project

To see how these forms API changes affect external projects, we only need to look at Material Design for Angular 2.

That team is still delivering their project with a dependency on RC0, likely to demo correctly at the conference and to support the new import structures. In their short term plans they are first releasing with the deprecated forms API in an upcoming alpha, and then moving to the new forms package. See #696 and #745 for details.

Changing the definition of “Core”?

We should take a step back here and look at what the Angular 2 team considered the core of the project. Until RC2, core included all of modules/@angular, such as:

  • @angular/core
  • @angular/common
  • @angular/compiler
  • @angular/browser
  • @angular/http
  • @angular/router

and other packages. But that might change.

After the RC2 changes, I (@krimple in the forum) participated in some discussion on Gitter about the API churn in RC2, which led to a comment that these APIs and maybe others could be cut from "core&quot. When he asked about whether the forms API was part of core, this was the response:


Rob Wormald @robwormald Jun 17 13:30[...]@krimple no, they [forms] are not, hence why they're getting moved into a new package [...] you (or anyone) could implement your own forms library on top of our /core APIs

The comment that forms is not part of core flies in the face of the fact that their own Material Design team wants to use the new Forms API as a bed for their forms library. At best, this is a question that needs to be posed to the Angular 2 team – what defines whether something is part of core? And if something as central as a forms API is not part of core, then what, exactly is it? Common code? Which is the original package it was part of?

Please note: Rob Wormald is one of the Angular 2 team members who is most open and available on Gitter to chat about Angular's current state and issues and he is a member of both the ngrx and Angular 2 teams. He is very engaged in the community, and communication with him helps us understand the Google team’s thinking.

Let’s keep in mind that we still do not have a stable Angular 2 forms API, that Angular 1.x had a forms API, so this is a new strategy. The Angular 2 team even included a “still in Angular 2” slide in ng-conf 2015 that listed forms as part of the Angular 2 platform. In ng-conf 2016 forms were omitted from the diagram entirely, not even included as a separate library. Writing a forms API on top of Angular 2 is not a trivial exercise, even for the core team. In fact, Angular Material 2 depends directly on the Angular team’s forms API.

Rob left a telling message about what they're considering overall:

Rob Wormald @robwormald Jun 17 13:27 writes: so[...] we probably should have been clearer about this at ngConf, but here's how we see it [...] we draw a big line between what we consider core and what's not. core is stuff that has hard cross dependencies [...] stuff that's not, we're moving to breaking them out into their own release cycles where appropriate [...] (eg, router, forms)

This seems to mean that the goalposts for what is "in" and "out" for Angular 2’s core has changed. I am not complaining about the fact that an open source team decided to change their minds. There is no warranty. That is the risk you take with adopting open source software.

Confusing our understanding of this comment, as this article was being finalized, the Vladivostok router team had merged their efforts into the @angular/router tree in the core repository.

Whatever happens here, there are questions about what the team considers in and out of core. Hopefully they clarify this over the coming weeks.

Many enterprises pick frameworks and platforms like Angular (and Spring in the Java world or Akka or Play in the Scala world) so that they get the majority of what they need out of the box. Those enterprises will have concerns if they don’t see the framework becoming more stable and settling on what it wants to deliver within a reasonable timeframe. And given the makeup of the project keeps shifting and the documentation isn’t getting much deeper, it is unclear to us when the projects that make up Angular 2 will settle down and what they will contain.

This churn is something to consider when planning on selecting Angular 2 for your upcoming project. We all have to mitigate risk with good planning for the benefit of our customers.

Final analysis: proceed with caution…

Though we have customers working on Angular 1.x projects today, and customers who are looking at Angular 2 as an option, we recommend caution when thinking of moving to Angular 2 any time soon. Though it is technically
in release candidate phase, that label may have been applied too early in the process. A release candidate should not be revamping critical parts of the platform and then jettisoning them as "not part of core" after discussing them for months, and even talking them up in their user conferences.

Angular 1.x developers should strongly consider staying with 1.x, and upgrading to 1.5 for any shorter-term deliverable. It is more stable, and has lots of useful features to keep things like digest cycles at bay with read-once bindings, debouncing events with ng-model-options and also a new directives API called components. And you can eventually migrate those components over to Angular 2 when you decide that it is ready.

Do the changes being made to Angular 2 make sense? In my opinion, yes. As we were developing the forms chapter of our training course, we found that the template and model-driven forms have similar semantics for comparable features, which makes them confusing to explain and use.

Also, the new router has some promise. That team of developers is extremely focused and wrote a ton of tests to lay the groundwork for that router. I suspect the reason it's not included in core is likely because they didn't want to be tied to a release schedule that might be forced too early or take too long.

The core of Angular 2 seems pretty well engineered. They thought of a lot of performance cases, and it's fast. TypeScript, while not universally loved, is a game changer in terms of developer productivity. You can actually truly refactor, go to source, find type bugs, and the like. The ecosystem is a bit of a mess, with changes in the type imports system (just in the past 1/2 year) from DefinitelyTyped to Typings to the future @types feature in NPM. So letting that settle down is probably a good plan before getting behind the wheel in an Angular 2 code base.

What do we recommend?

We don't recommend any one solution as everything in software depends on your cases and needs. If you are welcoming of bleeding edge, experimental, and want to see where Angular 2 is heading, then by all means, Angular 2 is an option. Just remember that you will be revamping code a lot over the next several months / year until they stabilize a release. You should also recognize a risk in their release processes and consider doing what you can to mitigate that with alternative plans.

The Ionic 2 team recognized that the router situation was a mess when they delivered their product, so they have their own solution, configured via their own directives and tags. We suspect the comment by Rob Wormald about implementing our own Forms API on core is telling: They are starting to think about Angular core as a smaller entity with satellite APIs such as forms, http and routing changing at their own rate.

If you want to help the Angular 2 team with Forms or with testing out the new router, by all means, dive in and test it, submit PRs, etc. But if you need those features for an application now, we’d suggest you wait until they are locked in.

Chariot Training courses: Updates to Angular 1, Angular 2 preview training available

What's the impact for my training team?

For Chariot's training course products, we will be updating our AngularJS 1.x Fundamentals and advanced AngularJS training in $http servers, directives and beyond this summer to cover 1.5 features and we can offer a preview of Angular 2 based on our current alpha course as an optional one or two day addition. Contact us for a private class and we can do it when you need it.

We are going to take a wait-and-see approach on Angular 2, evaluating each RC to determine if it is the right time to update our training again. But if you want a two-day custom course, again, we can deliver training based on the current state of the framework.

We are holding off on updating our sample repositories and blog posts for a few weeks while we press forward with other training business.

Resources for tracking Angular 2 development

There are a number of resources available to track the Angular 2 project, including: