Working on the Bleeding Edge – Building an Angular 2 Application During Beta Phase

6.6.2016

Roope Hakulinen

Roope Hakulinen

As a lead software developer Roope works as team lead & software architect in projects where failure is not an option. Currently Roope is leading a project for one of the world's largest furniture retailers.

Using a technology in a beta stage is often considered to be nerve-racking and time consuming as there are constant backward-incompatible changes and lots of bugs. Here’s what I observed while using Angular 2 during its beta phase. I also share some advice on how to get through the beta successfully.

Angular 2

Angular 2 has now gone through its alpha and beta stages as the first release candidate was published on 2nd of May, right on the rumored schedule in order to get it out before the ng-conf (the annual Angular conference) that will take place on 4th to 6th of the same month.

This blog post is a wrap-up from our experiences on using Angular 2 for four months now with an application built with our client, Netum Oy, who was ready to take a shot with the Angular 2. We are developing a system for applying and managing the European Regional Development Fund (ERDF) and the European Social Fund (ESF) regulated by Ministry of Employment and the Economy in Finland. This an enterprise Java application, implemented mostly with Apache Wicket until the beginning of this year, when we decided to implement the new parts of the application with RESTful resources and Angular 2 as frontend. Angular 2 had just reached its first beta at that point. To get familiar with Angular 2, you can read their official tutorial.

The choice was made based on traction gained by alpha online forums and actual experiences of another team working with it. This combined with the success of Angular 1 and backing by Google gave us the confidence to build on top of it.

The Experiences

So how has it been then? Great! At least most of time, that is. I took responsibility for keeping Angular and other dependencies up-to-date, relieving the rest of the team of a lot of the stress as it hasn’t been that trivial and straightforward in all cases to keep up with changes.

For the most part we have been satisfied with Angular 2. The framework has been stable enough and documentation has steadily become better. There has of course been some glitches on the way as you could expect. Here’s an unordered list of them:

New release almost once a week

Angular 2 dependent libraries lagging behind

Level of documentation

Outdated tutorials

No Stack Overflow coverage

New Release Almost Once a Week

There were 16 beta releases of Angular 2 between the December 15, 2015 (beta 0) and April 28, 2016 (beta 17) on Angular. The ”missing” 2 beta releases are the beta 4 and beta 5 which were declared as ”incorrect” by Angular team straight after they were published and were replaced by beta 6. Out of these 16 releases, 11 of them had breaking changes. This means that on average there were approximately 0.84 releases per week (16 releases, 19 weeks) during the beta phase. If you take out the first three weeks before the beta 1 (which was the first beta having any changes) was released, you get the average of 1 release per week.

This is both, a good and a bad thing, from our perspective. Having the changes brought to you constantly on small batches made it usually easy and painless to adapt to them. On the other hand, that meant you had to adapt constantly, taking time away from the actual development.

Angular 2 Dependent Libraries Lagging Behind

We use a few libraries that depend on the Angular 2 such as angular2-modal, ng2-file-upload and ng2-select. These libraries rely on more low-level stuff than our application which made it more regular for them to break when breaking changes were published. Even though their authors and other contributors have done excellent jobs on keeping them up-to-date, they inevitably have been lagging behind and thus not letting us upgrade to newest version before they have taken the actions required to upgrade.

Level of Documentation

The level of documentation was in general okay-ish. It has been evolving all the time and has became better. It can clearly be seen that the most important parts are covered better than the lower level parts. Yet, if you open up the documentation of, e.g. ngIf directive, you can see that there are couple of ”Not yet documented” sections left and it is one of the very basic directives used in templates.

If you look into some lower level class, you can see that they basically lack the documentation completely. Connection class is a good example.

Outdated Tutorials

The Web is full of tutorials from both Angular core team and community in general. These tutorials provide a great number of code snippets and examples. Unfortunately, not all of these are maintained, leading to a lot of confusion for newcomer.

No Stack Overflow Coverage

Stack Overflow is recognized nowadays as one of the most important resources for a programmer, and many of us visit it several times a day. Even though the number of questions and answers is constantly rising, the coverage is still relatively low and many questions are left forgotten without an answer. As with tutorials, the problem of outdated snippets applies to SO questions and answers as well.

Conclusions

Living on the edge comes always with a cost but there are few strategies that can be adopted to minimize the impact. First and the most important advice is to let others do the hard lifting by accepting a minor delay. In practice this means just waiting for a few days for the community to validate the new release. If there’s something seriously wrong with it, a new version will be published fast enough. You will also find some answers for common issues with the new releases. This also helps as the libraries are usually updated quite fast. But as they basically can’t be updated before the release, there will always be some delays. If you do adapt absolute edge versions, though, it is always a good idea to draft issues for updating the dependencies and even create pull requests for the libraries if possible.

The second strategy is to consider keeping up with new versions in spite of the constant releases. This will make it less of a pain in the long run and allow you to always use the newest functionality available.

In general, Angular 2 seems really promising and our team has been extremely happy with huge improvements, on one hand, in the daily development and, on the other hand, to user experience and performance when compared to earlier technologies. We have enough confidence to have it running on production already at this point.