Gofore has recently completed a number of large scale AngularJS migration projects. During these projects, we’ve gathered a lot of information on the whole Angular migration process from the motivation to migrate, down to the finer technical details of the migration itself.
The purpose of this blog is to catalogue this information and offer guidance to anyone that is considering migrating. Part 1 will focus on the reasons to migrate while part 2 will detail the tools and techniques available when doing the migration and the final part will focus on the migration itself in detail.
What do we mean by AngularJS and Angular?
As multiple versions of Angular were developed, differentiating between the two incompatible versions became more important. Blogs, projects and discussions had to establish which version of Angular they were compatible with.
To reduce confusion the Angular Team suggested a naming convention, AngularJS would refer to any 1.x version of Angular and these versions came before the major rewrite that resulted in Angular 2. Any version from 2.0 up would simply be referred to as Angular.
Why did Google decide to make such substantial changes to Angular?
As AngularJS grew in popularity and was being used for bigger and bigger applications, developers started to notice performance issues. In an interview in 2018 Stephen Fluin, Developer Advocate for Angular at Google looked back at the reasons why Angular was built and said:
“There were millions of AngularJS developers and millions of AngularJS apps. The cracks started showing. If you wrote an AngularJS app the wrong way and had thousands of things on the screen, it ended up getting very slow. The architecture was just not designed with this kind of large-scale usage in mind.”
As Google started to address the growing concerns in the development community they came to the realisation that revolutionary rather than evolutionary changes were needed, Stephen Fluin in the same article goes on to say:
“The Team realized that there wasn’t an easy path to make AngularJS what it needed to be. And that’s why Angular was born. We moved from, for example, a controller and template model into a more component-based model. We added a compilation step that solved whole categories of errors that people would make in AngularJS.”
Although Google continued to support AngularJS it was clear that the future would be focused on Angular and a concerted effort was made to encourage developers to move to the new platform.
What’s the Current AngularJS Landscape?
It’s difficult to quantify how many active AngularJS applications are currently in production however, in January 2018 Pete Bacon Darwin, AngularJS Lead Developer at Google stated:
“In October of 2017, the user base of Angular passed 1 million developers (based on 30 day users to our documentation), and became larger than the user base of AngularJS.”
From this, we can deduce that up until October 2017 AngularJS had a million active developers which would result in a lot of AngularJS applications. Pete Bacon Darwin goes on to say:
“We will release a couple more versions this summer that includes a few important features and fixes before we move into the mode of only making security and dependency related fixes, but that is all.”
Clearly Google’s goal is to move as many applications onto Angular as possible as they move AngularJS onto legacy support. For applications that are continuing to be developed perhaps this makes sense but what about legacy applications should they be migrated? Google’s current legacy support plan runs until June 30, 2021, after this point there is a risk that security and breaking issues will no longer be patched. Migration of legacy applications that will be used beyond this date should be considered.
Why Migrate?
Performance Increase
AngularJS can be an efficient framework for small applications but as projects develop and the number of scopes and bindings increases this has a significant impact on performance. In Angular 6 a new rendering engine was introduced which substantially decreased compilation time and bundle sizes while Web Workers and server-side rendering opens up the possibility for further significant performance boosts.
Language
Angular is built in TypeScript a typed language that compiles to JavaScript. TypeScript significantly reduces runtime errors by identifying them at an early stage. When writing code identifying errors early can speed up development time and increase stability.
Mobile Support
Unlike AngularJS, Angular is built from the ground up to support development across platforms. Angular components can be reused across multiple environments reducing the amount of duplication needed to get applications running on mobile devices. This and a smaller overall memory footprint makes Angular run faster on mobile devices.
Tooling Support
The inclusion of the Angular CLI allows developers to build services, modules and components quickly by utilising templates. This frees developers up to focus on building or improving on new features rather than writing boilerplate code.
Structure
AngularJS provides a flexible way of building applications that can quickly become unwieldy if not supported by strict coding standards. Angular imposes a structured component-based architecture to applications making building and maintaining larger applications much easier.
Data Binding
2-way data binding in AngularJS was one of the primary causes of the slowdown in larger applications. The bigger the application the more checks had to be done in each digest cycle. Angular’s change detection strategy eliminates the need to check branches where no changes have occurred significantly reducing the checks made in each digest cycle.
Updates
Google announced in July 2018 that AngularJS would enter a 3-year long time support stage. Updates would only be made if one of the following scenarios came about:
- A security flaw is detected in the 1.7.x branch of the framework
- One of the major browsers releases a version that will cause current production applications using AngularJS 1.7.x to stop working
- The jQuery library releases a version that will cause current production applications using AngularJS 1.7.x to stop working.
With support ending on June 30, 2021, there is a risk that security and breaking issues will no longer be patched.
Google strongly advise migrating and have moved to a structured timed release of updates for Angular with new versions being released every 6 months. Currently, Angular is at version 7 and Google has announced a roadmap to the end of 2019 with version 9. All major releases have at least 18 months of support and there are no plans for the kind of breaking changes that happened between AngularJS and Angular.
Part 2: Tools, Resources and Methods
In part 2 I’ll discuss the different methods for migrating an application and highlight the tools and resources that make it possible.
Sources
- Angular 1 and Angular 2 integration: the path to a seamless upgrade: https://blog.angularjs.org/2015/08/angular-1-and-angular-2-coexistence.html
- Ok… let me explain: it’s going to be Angular 4.0, or just Angular: https://blog.angularjs.org/2016/12/ok-let-me-explain-its-going-to-be.html#Its_just_Angular_39
- Interview with Stephen Fluin, Developer Advocate for Angular at Google: https://www.monterail.com/blog/angular-development-google-stephen-fluin
- Stable AngularJS and Long Term Support: https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c
You can read part 2 of this series here: https://gofore.com/en/migrating-from-angularjs-part-2/
You can read part 3 of this series here: https://gofore.com/en/migration-from-angularjs-part-3/
