Angular and AngularJS Hybrid
Updated: Apr 26, 2020
The model of constant iteration most Silicon Valley companies follow is typically inspired by the need for failing fast and moving with an Agile methodology. We are going to look into how Google used this approach to dramatically change the underlying framework to a new framework called Angular 2.
On April 30th, 2015, Google announced their newest version of Angular, then-called Angular 2. This was a massive change, and speaking as one developer to another developer, this may as well be a completely different framework. In 2015, I recall many developers throwing their hands in the air and screaming, “Everything is different!”. Luckily, Google had the foresight that the conversion from AngularJS to Angular would require a heavy lift from all parties that were using AngularJS. So, they gave these teams that were utilizing AngularJS as a framework over 5 years to finish translating their applications!
The 5 year window for developers to switch off of AngularJS may seem like ample time, but if you’ve ever met a developer, there are many more high priority issues that come up over “tech debt”. You have the product team coming to tell you what the users want, you have the sales and support teams saying there are bugs that are causing users to leave the system, and to top it off, you have this giant cloud looming over you to resolve the AngularJS End of Life (EOL). From a developer’s perspective, you may say, “Well, if we don’t resolve the AngularJS EOL issue, we won’t have any support, and our application will be much more vulnerable,” which is true. However, from the business perspective, you may say, “Well, we won’t be a sustainable business in 5 years if we don’t bring in revenue and retain the users we have.”
So, how do you find the middle ground when attempting to prioritize from two very separate methods of thinking? Well, if you are working full-time for a company, most likely you are in-need of a paycheck, so, you continue on as the AngularJS cloud becomes larger and larger.
Fast forward to slightly over a year until EOL, February 2020, and according to Similar Tech, there are roughly 70,000 active websites in the United States that are currently using AngularJS with only slightly over a year until End of Life! If we broaden the scope, there are well over 300,000 active websites that are using AngularJS throughout the world.
Check out the graphic that I used from Similar Tech to find the numbers
So, it’s quite easy to see which argument won, if you can’t keep the lights on, you won’t need to maintain anything. Now, with much less time, and much more code to translate, the importance for migrating away from AngularJS is becoming ever more important. Let me guess, you are faced with the question on: “How do I successfully migrate my application in the next 10 months (probably less time when you read this)?” In general, you are going to be given 1 of 3 options:
We completely rewrite everything in the framework we prefer
We write a hybrid application that enables us to build new features in our desired framework
We just continue doing AngularJS, what does the End Of Life even impact?
In the first option, the entire team can focus on rebuilding the application, and this will most likely completely inhibit your team from building new features during the timespan in which you rewrite the application. The time necessary to complete this rewrite is totally depending on the skillset of your developers, the size of your application, and the complexity of your application. Throughout the two code-bases I have re-built, (both were well over 100,000 lines of code) we had brilliant developers, and the AngularJS code wasn’t too complex. If we would have completely rewritten the application, with a team size of ~ 5-6 on each, it would have taken roughly 2-3 months based on standard work weeks. Even though new features would only be frozen for 2-3 months, we did not have the time or the money to completely stop building our application, so this was not the option.
In the third option, we have to determine what it means for a product to hit it’s EOL. According to Computer Hope, EOL signifies that a product is nearing the end of its lifecycle. The life cycle refers to the stages in which the product, in this case the software product, is no longer supported by the company that produced it. Okay, that doesn’t sound so bad, does it? Well, in theory, no, it doesn’t sound too bad. You can continue to use AngularJS, and you can continue to work with it as long as you have it archived. However, support documentation, npm plugins, and other very common and useful applications will no longer be supported either. In the end, you lose many useful tools in your shed, and development will become harder for you, and it will become exponentially harder for a new addition to your team to learn the intricacies of the framework. So, I would strongly recommend against this unless it is absolutely necessary.
Now, let’s dive into my personal favorite: the hybrid. The hybrid enables the continuation of new features, and it enables support of the existing application while transforming your codebase from AngularJS to your desired framework. As I mentioned before, I have successfully migrated two applications from AngularJS, and we used a hybrid application for both of these migrations. One of the migrations went from AngularJS to React, and the other code-base migration went from AngularJS to Angular. There are many other frameworks you can use, but for now, I’m going to stick with my personal experience.
As all choices in software development, there are pitfalls when attempting to balance a hybrid solution. There are the risks, which are pitfalls you can foresee, and there are uncertainties, which are pitfalls you cannot foresee at the beginning of development.
One of the risks that comes into play is that certain errors will be more difficult to debug due to the increase of complexity in your application. I can honestly say, this is partly true. However, I do believe that a good setup for the hybrid application will prevent bugs between the frameworks, as it has for mine.
Also, if you choose to run a setup with AngularJS and a larger application, such as React, you will experience heavier load times for the First Time User Experience (FTUE) because you will have to load both of your frameworks on the initial load. This can be mitigated in several ways, but this is definitely one thing to keep in mind!
However, the major pitfalls occur with team mentality. If you are going to move in the direction of the hybrid application, you MUST ensure that the entire team has the same alignment.
One of the major pitfalls that will occur in the absence of team alignment, is that you will create a bifurcated application. You are running two frameworks in your application, and it is probable that the simple solution in many cases will be to continue writing the application in AngularJS.
Simply put, your team is an expert in the AngularJS codebase and they are comfortable building their bug fix or small feature in AngularJS because it is far less risky in the short term. However, this is a fallacy that should not be taken lightly.
It’s very important to enforce the development in the new framework instead of the old framework because the time to completion will exponentially increase for every additional piece of logic in the AngularJS. Along these same lines, it is a fallacy to say something along the lines of “since we are refactoring our code, we might as well do xxxx”. The amount of overhead this creates on each component, file, or feature increases the time to completion drastically.
For instance, on each of these projects, we had very little test coverage due to the nature of our business and the state of our application (both were prosperous proof of concept applications). Not only did we decide to add testing, but we also wanted to add in Storybook, which is a fantastic tool we can use to build a component library. Requiring the addition for both better testing and more components in storybook greatly increased the overhead we needed to accomplish, which was added on top of learning the intricacies of a new framework.
Guess how long they took? One of them, which we allocated roughly 10 percent of our active sprint toward refactoring into the new framework, took two full years! Given the large amount of work we needed to complete, and the heavy overhead for migrating each component, we had our work cut out for us. In our other project, we were able to allocate roughly 20-25 percent and it only took 10 months. My point when considering the ramifications for adding more overhead on each component migration is that the time to complete this project is amplified greatly, so be careful!
In conclusion, if you are remotely considering the hybrid application, I would highly recommend this solution as long as you can create alignment across the entire team and organization. Depending on the structure of the code, it could take a decent amount of time to set up the hybrid, in my case it took roughly three weeks to see a working version of the hybrid application without any migrations. This is due to many different technical requirements, but this will only require 1-2 people working on this over three weeks, rather than the entire team. After the hybrid is up and running, it is pretty easy to migrate, which I will discuss in my next post :).
"Talent wins games, but teamwork and intelligence win championships." --Michael Jordan