With the recent change to SEMVER version numbering and the many architectural changes from AngularJS, looking at the recent advancements in the Angular community could give anyone a sense of impostor-syndrome. Also, staying up to date with the community could be considered a job in and of itself.
These rapid changes and restructuring of an open source web framework may prove to be challenging for agile and flexible dev shops, but they tend to carry more weight and raise more questions when seen through the lenses of an enterprise development shop.
Enterprise development usually follows a slower, more steady, and methodical process when it comes to drastic changes in architecture and development practices. However, this is due to the nature of enterprise businesses, where application development is rapid and tends to support various business functions. As a general rule, the more line of business applications that are developed, the more prevalent conversations around support models and technical debt start becoming. As productive and well intentioned these conversations may be, they tend to halt any advancement in shifting frameworks and development processes. This occasionally locks developers into working with an older framework simply because upgrading could take months due to lack of resourcing.
With AngularJS now fading into the background and Angular gaining more acceptance and a larger following, it raises the question:
How should enterprise developers approach upgrading their existing line of business application codebases to leverage the new improvements made within Angular?
In this article, I want to argue that perhaps your best bet is in fact a ground-up rewrite. But before we get to why, let’s look at the primary upgrade strategies.
There are many articles and even e-books dedicated to proposing a strategy to migrate existing AngularJS applications to Angular. Some of these strategies are more involved in terms of the development effort. Others far less, but both prove to be an issue in terms of performance and managing the upgrade itself amongst teams.
Victor Savkin has a few articles around the two most popular methods for upgrading: vertical and horizontal slicing. Both strategies leverage to some extent NgUpgrade, a library authored by the Angular team that allows you to bootstrap AngularJS applications within Angular.
Without getting into too much detail, here’s a brief overview of each strategy geared towards upgrading brownfield AngularJS web applications.
Vertical slicing allows you to upgrade individual routes, features, or screens – one at a time. This is somewhat similar to a top-down approach. You either are within the AngularJS or Angular portion of the web application, but not in both at the same time.
One of the downsides of this upgrade strategy is the duplication that needs to take place. For instance, if you were to upgrade
/routes/route1 to Angular, you’d need to keep that route in AngularJS while you are working on the Angular rewrite.
This approach may not be practical for some teams or applications at it is not that well suited for teams attempting to follow a more fast paced, continuous release strategy. Teams following this strategy will spend most of their time upgrading a screen that may have many controllers, parent and child-routes, all of which would need to be rewritten to Angular. Releases would end up being mostly around a specific route or screen that has been upgraded to Angular rather than any notable improvements to the application.
On the other hand, the horizontal slicing strategy is focused around upgrading individual components within your application. This is somewhat similar to a bottom-up approach. One of the downsides to this strategy is that you are loading the entire AngularJS and Angular frameworks within your application. Because it avoids the encapsulation of a single screen or route being upgraded to Angular (as in vertical slicing), you’ll need to load both frameworks within a single screen. However, you’ll be able to work your way to the root of the application, upgrading inputs, directives, and routes one at a time. You’ll also be able to deploy these changes at a faster pace.
NgUpgrade is without a doubt a great tool in itself, allowing developers to mix and match strategies that allows them to work with existing AngularJS codebases while slowly making their way towards Angular. However, both of the strategies mentioned above are nonetheless geared towards the large AngularJS applications that have many routes, controllers, views and complex dependencies.
Upgrading to Angular may seem like the obvious answer to many development shops, some of which support and develop large AngularJS applications. However, the topic of upgrading becomes a bit fuzzier when speaking in terms of small and focused line of business applications.
Enterprise development is characterized as fast-paced and generally performed with extremely short time-lines, this leads to framework decisions and upgrade talks becoming an ordeal in themselves. Typically, enterprise development teams support numerous small and focused applications, which proves to be an issue when it comes time to think about how to migrate every single one of those applications to a new framework.
With the upgrade strategies commonly mentioned on many articles and Angular books, the enterprise developer usually either picks one or the other. The next questions typically be asked are:
Given the short lifespan of many line of business applications, the latter statement may never actually be a valid option.
If you look at Angular as a new framework rather than an upgrade, the effort required to effectively convert an application may not always make it the appropriate answer.
Let’s take for example, an application that has a few screens that are mainly focused around displaying data and allowing the user to filter and export to Excel. Furthermore, this hypothetical application has limited support and is only used by one department, with talks of said department investing in a third party tool that would essentially yield the web application obsolete in the near future. Within the next couple of fiscal years, the application will eventually become decommissioned. Upgrading in this case is probably not worth the effort or time.
Analysis like these are important, and should be done well before developers take on an upgrade plan for line of business applications. By looking at the bigger picture and understanding the effort and benefits of upgrading, it’s fairly straightforward to say that an upgrade may not be the answer for some applications currently leveraging AngularJS.
That said, there are many instances where a third-party tool may replace an AngularJS application in the longer term, but additional features may be added well before that occurs. At which point, it’s important to determine the scope of such additional features, and whether they would benefit from leveraging Angular over AngularJS. It may essentially make sense to upgrade this application by leveraging vertical slicing, and only develop the new features within the Angular side of the application.
There is also a third option for some enterprise level applications where there is no planned roadmap to shift to a third party software as a service provider, and where new features are within the scope of the application’s lifecycle. Let’s assume that such applications are used across many departments and support business critical functions. These applications are somewhat special, in that they are a great candidate for upgrading by simply looking at the extended support that would be needed and the additional effort in developing new features.
Let’s assume that your team has completed their overview and have concluded that the planned features within the application’s roadmap could benefit from leveraging Angular’s AOT compilation or some other Angular feature that improves performance. It’s now important to understand and consider the third option in upgrading to Angular, and that’s rewriting the codebase.
I think many developers and architects cringe at the idea of rewriting a business critical application simply because there is a newer and faster framework. It’s understandable – the effort in itself would require days or even months of development, additional developer resourcing, budget to account for loss of productivity in terms of releasing features at a rapid pace, and the list goes on. However, is it really such a terrible idea to rewrite a codebase if the longer term benefits outweigh the short term complications?
As an enterprise developer, I can safely say yes, it’s worth the short term headache. When looking at an enterprise development shop that only works with AngularJS, I’ll admit that moving to Angular does not seem like an easy task. Part of the battle is shifting greenfield application development to Angular, that may be a major win on its own. However, the brownfield application development is where the problems start to arise.
When taking into account the lack of familiarity with Angular as a new framework, the training required to get AngularJS developers up to speed with Angular, and the effort required to upgrade using NgUpgrade strategies, in my opinion, rewriting the codebase within its own project may be the best conceivable choice in the long run. This would allow developers to imerse themselves within a full Angular codebase without the need to context switch and deal with complex refactoring logic.
Furthermore, NgUpgrade strategies are geared more towards AngularJS applications that have gradually been upgraded to versions 1.3 and above. This also includes the subtle changes in controller definition such as using
controllerAs, moving towards component directives, and somehow accounting for the overuse of
$rootScope instead of well defined services among other AngularJS prior refactoring.
There are also other basic considerations such as file structure, third-party directive dependencies and many other constraints that essentially create refactoring nightmares when switching to Angular from older AngularJS applications. Unfortunately, these issues may be more prominent in an enterprise setting. As many enterprise developers can attest, when working within a short enterprise development timeline and clients that don’t always have a well-defined vision for an application, development is usually done without first taking into account all the recommendations suggested by the style guides.
Another important concept to grasp when looking to upgrade a codebase is the technical debt that would be incurred. If for example, upgrading using the vertical slicing strategy is your team’s preferred choice, your team would then need to eventually work towards a full upgrade. However, if any other priority comes along and your team is forced to abandon an upgrade to Angular, then you are left with a half AngularJS and half Angular application. Supporting this application may become rather difficult as new developers are on-boarded or the priority is continuously shifted away from your upgrade efforts.
It’s safe to say that upgrading from AngularJS to Angular is not an easy task, and this is in large part because Angular is sort of a new framework on its own. Considering NgUpgrade strategies and the various other considerations within an enterprise development shop, rewriting an application to leverage Angular may sometimes be the best choice when it comes to practical and efficient use of time and resources.
For Enterprise Applications that tend to have a single purpose and are fairly focused to solve a line of business problem, rewrites will usually tend to pay off more in terms of saved effort and effectiveness.
However, every development shop is different and, as such, there is no right or wrong way to approach this problem. What I’ve come to find is that enterprise developers are in a great spot when it comes to leveraging Angular’s new features. Due to the nature of our development efforts and our rapid application deployments, we can start using this new and exciting framework, and enable our business users by delivering exceptional web application experiences.
Moving to Angular and leaving AngularJS behind is certainly a great choice, even if your decision for the moment is to support legacy applications in AngularJS and use Angular for all greenfield applications – that’s certainly a great way to start this move.