Our Journey from Angular v1.x to v5 and Beyond
This post talks about KeepTruckin’s frontend stack history and its evolution over the last few years. We disclose the reasons for our specific framework and language choices, and explain the importance of keeping up with new framework versions. We also discuss how, over time, it became clearer that we should stick with Angular as our framework.
What KeepTruckin does is connect the world’s trucks. Our electronic logging devices and fleet management platform bring the trucking industry online. The frontend product discussed in this post is KeepTruckin’s Fleet Management Dashboard app, an Angular-based web application used by fleet managers and dispatchers of the fleets who use KeepTruckin.
The initial version of our dashboard was built in AngularJS back in 2014. Keep reading to walk through our frontend journey from 2014 to 2019 with us. In this post, we showcase the engineering decisions we made and the lessons we learned while working with the Angular framework.
Why We Used AngularJS
AngularJS was one of the emerging frameworks when we were developing the initial version of our dashboard in 2014. Some features that made us choose this framework over others were:
- two-way data binding
- MVVM architecture
- declarative user interface
- dependency injection
- POJO (plain old Java objects) data models
But our primary reasons for choosing it over other options, such as BackboneJS or KnockoutJS, was that AngularJS was better suited for large applications, and backed by Google.
Choosing CoffeeScript Over ES5
When we started writing our code base, ES5 was the mainstream JavaScript version and lacked features required by large scale applications (features such as modules, classes, promises, etc.). Our main reason for using CoffeeScript was that it prevents developers from using the unwanted parts of JavaScript, and improves code readability. CoffeeScript introduced features like class structure and lambda functions; these allowed us to better divide and encapsulate our code, and write less code to achieve more.
Problems with AngularJS and the Need to Upgrade
We encountered multiple problems when the application started to grow in complexity. The most significant problem was the performance issue caused by the two-way binding, which was implemented using an inefficient change detection mechanism. Apart from that, AngularJS lacked an easy way to lazy load modules, and a straightforward way to integrate third-party libraries.
Upgrading to Angular v2
The new Angular framework (v2.x) solved all of the AngularJS (v1.x) problems. It differed drastically from the API perspective, but the majority of its concepts remained the same. Thus it was an obvious choice for us to upgrade to Angular v2 instead of changing frameworks altogether.
Some improvements in the new version were:
- lazy loading of modules
- the component-based architecture making it modular in structure
- improved performance with new change detection
- powerful routing
- HTML-standard-based template syntax
- reduction of code with ahead-of-time (AOT) compilation, which improves boot time and overall performance
When upgrading to Angular v2, we decided to use JavaScript’s ES6 standard because it offered most of the features previously introduced in CoffeeScript. In addition, CoffeeScript was slowly dying as a result of the web community’s focus shift to standardizing useful features in EcmaScript standards.
At the time of this migration, we were a team of four, and it took us three months to release our initial beta based on this new Angular version. In addition to migration, we integrated a completely new UI design in the same timeframe.
The Challenges of Upgrading Without Angular CLI
Angular v2 was in beta when we started migrating our code from AngularJS, and Angular CLI was in a very early stage, so we configured our build system manually, using Webpack. This was challenging because there wasn’t much documentation about setting up Angular projects with Webpack available online.
Enabling Ahead-of-Time (AOT) Compilation
Once our upgrade process was complete, we started our optimization process. At the time, there was no AOT compilation support for JavaScript, leaving us no choice but to migrate our code to TypeScript. In addition, we had to use relative paths for file imports because absolute paths were not working.
Enabling AOT not only significantly reduced boot time, but also improved the web app’s responsiveness. We observed an improvement of approximately 30% faster load times and responsiveness. Such a dramatic improvement from AOT compilation is possible because it compiles the code into efficient JavaScript and removes Angular compiler code from the build bundle, thus reducing the build size.
Migration to TypeScript
When we started using TypeScript, we realized its benefits and greatly enjoyed the new language. Because TypeScript is a superset of JavaScript, our learning curve was negligible.
TypeScript offers optional static typing, but we made its use mandatory because it helped us catch most errors at compile time. In addition, we could use new JavaScript features which were not yet supported by all browsers.
One of the biggest advantages of TypeScript is its code completion and IntelliSense. Because Angular itself is written in TypeScript, code editors can present all the methods available along with expected arguments.
What’s Next
Angular v5 → Angular v6
Currently our app is running on Angular v5, and our plan for the coming year is to upgrade Angular all the way to its latest version, which is currently v9. The immediate next step toward that goal is for us to migrate to Angular v6, and the prerequisite for Angular v6 is to move to RxJS v6.
RxJS v5 → RxJS v6
We are already in the process of migrating our code base from RxJS v5 to v6. Our first step was to use the RxJS v6 new pipe syntax while remaining on RxJS v5, because v5 supports pipes as an option, whereas they are made mandatory in RxJS v6. We believe that after this change, we will be able to migrate to Angular v6 with minimal changes.
Webpack → Angular CLI
Once we’re on Angular 6, and before we migrate to Angular v9, we will first move from Webpack to Angular CLI. As we mentioned earlier in this post, the build system of our code base is configured manually using Webpack only, because CLI was in its alpha stage at the time of our initial migration. We are currently in the planning phase of our move to the CLI.
Languages and Tools → Maximizing the Power of the Framework
With the passage of time, Angular and its tools have matured and we’re (almost) out of the phase of confusion caused by switching between different languages. Once we’ve moved to the Angular CLI, we will finally find ourselves settled in a place where we can concentrate fully on extracting the power of the framework instead of juggling between languages and build tools.
