Angular is a well-known TypeScript-based frontend framework used to build scalable single-page applications. Although new frameworks like React have taken over frontend development, Angular is still one of the best frameworks to start a new web-based project.
I’ve been working with Angular for a significant period, and it has some great features with constant updates. However, Angular is not a silver bullet. It has some significant drawbacks and challenges that bring nightmares to developers.
Personally, I have also faced some of these nightmares when using Angular. As we all know the spooky season doesn’t end with Halloween, so I think this is a good time as any to share them with you. So, in this article, I’ll share my Angular nightmares, the ones that make my skin crawl.
Without a doubt, that is the biggest nightmare of any Angular developer. But before discussing it, let’s look at the Angular version history.
AngularJS is the initial version of Angular, introduced in 2010. Then, the Angular team waited six years for a major release and introduced a new version of Angular named angular 2 in 2016. After that, we received 11 major updates from Angular, from Angular 4 to Angular 14 (Angular didn’t release a version as Angular 3). When we compare those versions’ differences, the biggest and most significant change was between AngularJS and Angular 2. AngularJS is a JavaScript-based framework, whereas all the later versions are based on TypeScript. In addition, newer versions have many features like dependency injection to make developers’ work easier.
Between 2010 and 2016, many companies opted to use Angular for their applications. Once the newer versions were introduced, most companies decided to stick to AngularJS while some revamped their application with new versions. But, as time passed, it became harder to maintain AngularJS applications due to the lack of updates, third-party library support, and developer interests. So, the need to migrate became essential for many applications.
There are three approaches we can use to migrate from AngularJS to Angular:
-
Rewriting the application.
-
Updating the existing application.
-
Following a hybrid model.
Rewriting the Application
Rewriting an application is almost identical to creating a new application. This road is taken when the old application has outdated libraries, design principles, or design patterns. In such cases, trying to update the application will be more complicated than creating a new application.
However, rewriting an application can take a significant amount of time and effort from your development team. Hence this approach is not suitable for large-scale applications. On the other hand, rewriting the application will give you the flexibility and freedom to organise the codebase as you prefer. Also, you can use modern application development principles and designs in the new application.
Updating the Existing Application
Updating the existing application is the easiest way to migrate from AngularJS to Angular. You can use this approach to any scale application, and it will not take as much time and effort as rewriting. But updating doesn’t give you the same flexibility as rewriting to add state-of-the-art concepts.
In addition, you need to divide the application into parts and gradually update while testing to ensure all the functionalities are working as expected after the update. This approach is most suitable for large-scale applications, since rewriting them can take ages.
Following a Hybrid Model
Updating or rewriting an application requires developers to put in extra effort or delay any ongoing implementation since they need to focus on the migration. But, sometimes, the organisation or the clients can’t afford to delay new implementations or hire a separate team for the migration. In such situations, you’ll have to follow a hybrid model.
In the hybrid model, you have to keep the old AngularJS code without any change and implement new modules using a newer Angular version. Compared to the other 2, this approach will take significantly less configuration time. However, you’ll have to maintain separate libraries, specifically configure things like routing, styling, and translations for both Angular versions.
As you can understand, there is no ideal migration method. Before making a decision, you have to consider the advantages and disadvantages of these approaches, project requirements, time frame, client concerns, and many other things. That is why migrating from AnguarJS to Angular has become such a nightmare for developers.
Using third-party JavaScript libraries is another challenge we face when using Angular. Since Angular uses TypeScript, it is essential to ponder the compatibility between the library and the code base before using it. However, most libraries now support TypeScript and provide another version of the same library named @types. For example, if we ponder the node library, it has another version named @types/node with TypeScript compatibility.
But sometimes, there can be a specific library you need to use which doesn’t provide a TypeScript-compatible version. You must manually handle such situations by creating a local declaration. Installing an unsupported library without making a local declaration can cause unexpected errors in the application. You might spend significant time resolving these errors without identifying the root cause.
So, we must pay extra attention when working with third-party JavaScript libraries in Angular. There are three ways to create a local declaration, and I will briefly explain them to give you a better understanding.
1. Adding to index.html
Include the library in the index.html file using a script tag.
2. Adding to angular.json
Include the library in the script section of the angular.json file
"scripts": [ "node-modules/tinymce/tinymce.min.js", ],
3. Importing the library into component
You can directly import the JavaScript file into the Angular component.
import * as tinymce from'tinymce/tinymce.min.js';
Search engine optimization (SEO) is an essential aspect of modern web applications. But, implementing search engine-optimized applications using a framework like Angular is a challenging task.
As we all know, Angular applications are single-page applications (SPA), and they are rendered on the client side. Hence, web crawlers can’t access the complete structure and content of the application to rank the application in search results properly.
So, we have to use workarounds or additional libraries to improve the SEO capabilities of Angular applications. For example, we can use methods like:
-
Using dynamic rendering tools to create static HTML files.
-
Dynamically update page title and metadata.
-
Using Angular Universal to enable serverside rendering.
All these methods require a significant amount of extra effort and time. Frameworks like Next.js have made SEO super easy with built-in features, while Angular asks you to do most of the work. That’s why SEO has become another nightmare for Angular developers.
By default, Angular is a fast and performance-focused framework. It provides various built-in performance optimisation techniques like AOT, lazy loading, OnPush change detection, and more to help developers to make applications faster.
But, performance issues are inevitable, and unexpected problems can arise when the application scales with complex requirements. So, we need to run performance tests continuously to detect abnormalities, since most of the performance issues are undetectable to the naked eye.
However, fixing these issues is much more complicated than finding them. We need to consider all the possible root causes, analyze them one by one, apply potential fixes and compare the new test results with previous ones to see if there is an improvement. Sometimes, this process can take up to a few days. That’s why debugging performance issues has become one of the most challenging tasks in Angular applications.
Implementing localization in Angular is pretty straightforward. You can use libraries like @angular/localize, ngx-trnslate, and I18next to simplify things even more.
However, there are some challenges you may face after the implementation. For example, Angular localization does not support automation very much. So, if your application is actively scaling, you’ll have to handle multiple translation files manually. As a solution, you’ll have to use a third-party library like @ngx-i18nsupport/tooling to automate the process.
In addition, you’ll have to handle multiple bundles when you build and deploy the application. When you make a deployment, you must redeploy all the locale builds, and it won’t be easy to automate the deployment process.
Compared to the other four challenges discussed, localization challenges might not be that critical since most issues are related to automation. But sometimes, these small issues can create chaos in your pipelines.
I discussed the five biggest challenges a developer can face when working with Angular. I called them Angular nightmares since most of these issues don’t have straightforward solutions, and developers won’t have a good sleep until the issues are resolved.
I hope my experience with these Angular nightmares will help you reduce the time and effort you put into addressing these challenges. Thank you for reading!
Source: https://cult.honeypot.io/reads/my-angular-nightmares
