Working many years with angular I found it hard to create the structure of a project. The main reason for that struggle lay behind the way Angular interacts with components and modules. The following article explains what is the issue with NgModule and whether is going to change in the foreseeable future.

Builtin lazy loading mechanisms

Angular has NgModule based architecture. In other words, each application has at least one NgModule which connects all the components and routes together. It is a practical approach for applications structure. An application has a central unit that contains all the declarations. That’s right when we are talking about small web apps.

When working with large Single Page Applications performance becomes a critical pain point. It is a time to start thinking about optimization. One of the ways to reduce loading times is to minify application size on the first load. This goal can be achieved with lazy loading. The technique is supported by angular routing mechanisms.

The technique allows loading specific parts of an application only when needed. Here is the full documentation on how to implement lazy loading within Angular framework.

What is wrong with NgModules?

Up to now, all seems correct, right? Let’s zoom in to see whether potential issues could pop up.

For instance, we will take the Angular Material UI. The framework should comply with best practices because it is built and maintained by the Angular team. Looking at the components provided you may mention that each of them has its own NgModule. It is done to allow importing of a single component without grabbing all them and overloading the application.

What does all that mean for me as a developer? Practically you will need to create a NgModule for each of the components. Thus double action on each component creation.

For newbies, the concept may appear quite painful. To be honest for me to work in this way is still frustrating.

VueJs components interaction

When I started to work with VueJs I didn’t feel any discomfort. Just after some period of time mentioned I am doing fewer actions to achieve the same component interactions than I was doing in Angular. “How could it be?” I thought. Just after side by side comparison, figured out what was missing through all the development process with VueJs. The answer was “modules”.

In VueJs all is based on components. Do you want to create a page? Make a component. Do you want to create a reusable UI piece of code? Make component! Nothing more. Just that easy.

Aren’t modules making a more coherent structure? Correct me if I am wrong, but I didn’t mention any practical benefit of this additional architecture layer yet.

Is it going to change?

Yes, the Angular roadmap gives all Angular developers a ray of hope. The proposal was explained and discussed in this “[Complete] RFC: Standalone components, directives and pipes — making Angular’s NgModules optional”.

Yet, pay attention to this statement:

This proposal is not trying to remove the concept of a NgModule from Angular — it is rather making it optional for typical application development tasks.
At the same time we believe that it paves the path towards greatly reducing the role of NgModule for typical development scenarios — to the point that some time in the future it would be possible and reasonable for us to consider removing it altogether.

To conclude

Getting rid of modules is the first step towards Angular architecture simplification. So far I see only benefits in that act.

Who knows maybe in the future Angular will adopt a functional components approach as React did instead of classes.