What to consider when upgrading from AngularJS to Angular 2.0+
What to consider when upgrading from AngularJS to Angular 2.0+
For the last year we have been working with a large corporate client with 20+ web applications written in AngularJS (version 1.5 to be exact). Following Google’s announcement earlier this year, it became clear that the client would need to upgrade all of those applications to a more modern front-end framework.
The main reason behind this was Google’s pulling the plug on support from the 30th June 2021. Any security holes found beyond that point would leave our client vulnerable unless they took responsibility for rolling out patches to the framework themselves. We knew that we needed a new framework but the first, big challenge was deciding which one to pick and how to do it.
The ‘Big Three’ of Front-end Web in 2018
We could have easily chosen the latest version of Angular (v6.2 at the time of writing) but we felt duty-bound to explore all possible options before settling on one and making quite a big commitment. The two other contenders we considered were Vue and React.
Although it has backing from organisations with the stature of Ali Baba, Vue was taken out of the running quite early on. While increasing in popularity at an impressive rate, the community is relatively small which represented a risk. this was a risk only worth taking if Vue offered features that were crucial for what we were doing, but this wasn’t the case.
Despite its huge popularity, we also took React out of the race. It’s a library rather than a full framework, which would have been fine except that we needed to make sure not a single piece of the AngularJS framework remained when we were finished.
React would have meant having to find other libraries to handle routing and data storage and largely devising our own architecture, which was simply not feasible when Angular 2.0+ offered all of this functionality ‘out of the box’.
Replacing a front-end framework is a huge task in itself and we wanted to minimise the work required. For the same reason, we decided not to make changes to any of the tools we used for deployment or automated testing.
The real clincher was the ngUpgrade module offered by Angular. Not only is this officially supported as an ‘upgrade path’ by Google, but even better, there are many real world examples all over the web which we could follow. There is even a whole course built solely around this subject which explained the process step-by-step.
While we wanted to change as little as possible, there were a few cases where we didn’t have a choice. Some Node.js modules used by our AngularJS app only play ball with version 6.0 and below, while Angular 2.0+ requires at least v8.0. We also had to add a compiler since we were introducing TypeScript but this was a boon because we chose Webpack.
‘Bonus’ Benefits
New technology is created as a result of the communities who maintain it needing to create it in search of new functionality. So the simple fact of upgrading gave us benefits we hadn’t specifically sought but we got nonetheless.
Webpack includes support for lazy loading, meaning the browser only downloads the assets required to render what’s visible in the viewport. This is great for performance because it reduces the amount of Javascript to be parsed, as well as the download fingerprint which is a big deal for a big international brand where you can’t guarantee the network conditions across diverse markets. While it was possible to port a lot of our AngularJS code with only minor changes, there were areas that required significant refactoring. We took this as an opportunity to optimise the code in other ways including some changes to the data model which reduced service calls.
The need for refactoring is mainly driven by Angular 2.0+ encouraging a component-based architecture (versus Model-View-Controller for AngularJS) and with good reason; it makes your code more modular which was also brilliant for reusability and testability.
Our Approach
The ngUpgrade module allows one to bootstrap AngularJS into Angular 2.0+ so components can be built in both frameworks and run in the same application while sharing data and services. The two frameworks could co-exist indefinitely while still allowing us to continue pushing updates to production. This allows an incremental upgrade, starting with the smallest component upwards.
The alternative would have been a more waterfall approach which could have resulted in working on a staging server until the upgrade was ‘complete’: an absolute anti-pattern for large, complex applications where that process can take years.
A software development team constantly juggles priorities. The idea of dropping everything to focus on the upgrade would have been completely unpalatable to our customers and our business stakeholders especially when after all this work, the final product would look exactly the same with no additional features.
It wasn’t all roses however… Angular mandated TypeScript which could have been potentially jarring for front-end developers who hadn’t known anything other than Javascript. It was a superset of Javascript so a lot of the additional features were optional but there was still a steep learning curve. However, for a large project with multiple teams working on the same code, TypeScript did make it easier for all of them to understand new code when they were working on otherwise unfamiliar parts of the codebase.
Final thoughts…
We were really happy with the solution we came up with in the end, though obviously, it would have been easier if Google had never forked AngularJS/Angular in the first place.
There were also no guarantees a similar situation wouldn’t arise in the future even though Google must have recognised the pain they caused for many developers having once been a leading framework and now, trailing React as a huge portion of the community has jumped ship.
This suggested that in the future, they would err towards more incremental updates which would be easier to keep up with, and certainly this has been the case so far. From this point of view, the upgrade is a process worth going through for our client if only for the fact it’s only going to get harder as Angular gallops on; and more urgent as the deadline looms.