Today we are going to make a meaningful effort to investigate the transition from AngularJS to Angular and make out the main pitfalls within this process. Considering Angular as a platform for professionals, we decided to highlight the main points why being experienced with this framework is a must have.
So, what does Angular give you?
Angular allows creating large and complex applications in terms of business logic right out of the box. Angular became a complete reinterpretation of AngularJS - probably it was the most painful point, but it was worth it. The framework itself became much cleaner and flexible, more enterprise-like and from this point of view, it had provided higher scalability. Angular main advantages are:
- Microsoft and Google support;
- Having Developer Tools (CLI);
- Allows the unified project structure;
- Having TypeScript out of the box: (allows writing strongly typed code);
- Reactive programming using RxJS library;
- The only framework with Dependency Injection out of the box;
- HTML based templates;
- Cross-browser Shadow DOM out of the box (or its emulation);
- Cross-browser support for HTTP, WebSockets, Service Workers;
- No need to customize anything; no more wrappers;
- More modern than AngularJS;
- Vast community.
And let’s highlight the disadvantages to remain honest. Angular takes a higher barrier to entry because of Observable (RxJS) and Dependency Injection. If you want everything to work well and quickly, you would need to spend some time on additional optimizations - angular is not “super” fast, but it is many times faster than AngularJS and it develops its speed with each new version. As a matter of fact, if you plan to develop a large enterprise application, then you won’t have an architecture for managing the state from the “box” - you would need to add Mobx, Redux, CQRS / CQS or another state-manager. Also, dynamic component creation turns out to be quite a non-trivial task.
But to all intents and purposes, all these disadvantages are leveled by the developer’s own experience.
Why someone would need switching from AngularJS to Angular?
First of all, Angular is faster, easier and more convenient. It has fewer bugs (e.g. templates typing helps to get rid of them). Those benefits had already been defined since Angular 2 release, but looking back at the past everyone was scared a bit: what if Google decides to turn everything upside down again with the next version, without backward compatibility? Having a big project the transition to an essentially new framework requires serious resources. But reviewing the latest versions of Angular allows hoping that there will be no more revolutions, which means that it is time to migrate.
Secondly, using Angular allows updating the technologies used in the platform. If this is not done according to the principle “if something doesn’t break, you don’t need to repair it”, a developer will be able to figure out that further progress is possible only if the platform would be rewritten from scratch. But someday or another switching over to Angular in terms of optimization could easily become the best option, so the sooner this is done, the cheaper the transition would be. As the amount of code increases continuously, it is a must-have for developers to get benefits from the new technology as earlier as possible.
And finally, a third important reason is developers. Some developers consider AngularJS to be a relic of the past: it successfully performs duties imposed to it, but it had stopped its development. If the platform is constantly growing and the company has a team consisting of strong developers, they are always interested in new technologies, not in dealing with an outdated framework, so the transition to Angular makes the job more interesting for strong candidates.
How to transfer?
There is an ability to perform the transition in a parallel mode so that the platform works on AngularJS, a developer writes the new version from scratch and then tests it and at some point simply switch the toggle. The second option is a hybrid mode, where changes occur directly on the production where both AngularJS and Angular work simultaneously. Fortunately, this mode is well thought out and documented.
The choice between hybrid and parallel transition depends on how actively the product is developing. In case of parallel approach there are fewer dependencies (although the code was about the same), and most importantly, it is possible to stop all development process and only deal with the transition.
Choosing a parallel transition takes some risks as well. At the stage when the new version is being prepared the entire development process is freezing. There is a chance that the process will be delayed no matter how accurately you would calculate the move date, because developers could face an obstacle, having no clue about the next step. In this situation if you still have the current working version of the app in production it would be better to just stop and calmly look for a solution: live app may not work as effectively and a bit hardcoded, but there are no processes stopped at least. Also, it is worth keeping in mind that the transition process could really take a long time gap - you could plan for 400 hours but in fact, you would turn out twice as long.
But In general, the hybrid transition should not be considered as a plan B. According to the developers of Angular themselves it is a completely standard procedure not necessary to be afraid of.
Here is how a basic sequence of actions should look like within the hybrid transition:
- Initialization of the hybrid application. The main idea is to make a hybrid app, which would launch AngularJS by wrapping it in Angular. In this case, everything remains as it is, but starting from this point the app would assemble slower and its startup time would increase (while the hybrid model is working). Since our angular is is wrapped, we won’t have any opportunity to adjust the page title; all the work with title/favicon/meta tags would be placed within services that directly interact with the necessary elements.
- Transferring services to Angular (the easiest part): rewritten services quickly become available from AngularJS, on which components are still running, starting from the most simple (having no dependencies) to more complex ones.
- Drawing the rest of the picture: transferring the basic components (GUI and everything that does not require usage of other components/directives). It is better to transfer components from the bottom up by the unit as far as it’s possible.
- Transferring page components and getting rid of AngularJS.
Having experienced Angular and AngularJS at multiple projects we can say that Angular has become more professional, high-quality a truly corporate framework, using which you can finally get rid of being afraid to build large applications. This was achieved due to the rethinking of previous experience with the first version of Angular and the chain of correctly made decisions (e.g. the choice of RxJs and Typescript, by the way, when you need to hire typescript developers, feel free to contact me) and their integrity.
Of course, in Angular, you can still create chaos, but it is pretty difficult thing to do as incorrectly constructed code immediately pops up either when evaluating performance or when trying to reuse it. It will surely make you feel that it was created by people who have extensive experience in practical development.
We recommend you read our new article on how to migrate AngularJS to React.
