The Case for Removing NgModule in Angular
After years of building Angular applications, I have often found it challenging to define a clear project structure. Much of this difficulty stems from the way Angular manages the relationship between components and modules. This article looks at what makes NgModule problematic and whether the framework intends to change this setup anytime soon.
How Native Lazy Loading Works
Angular's architecture is built around NgModule. That means every application needs at least one module to bind together its components and routes. For smaller web projects, this setup works well. It provides a central place where all declarations are registered, which keeps things tidy and manageable.
However, when you're working with larger single-page applications, performance becomes a serious bottleneck. The need to optimize becomes apparent quickly. A common strategy is to shrink the amount of code sent to the browser on the initial load. Lazy loading is the go-to technique for this, and Angular's routing handles it natively. This lets you load certain application segments only when the user actually requests them. You can find the official guide online for implementing lazy loading in Angular.
The Core Problem with NgModule
On the surface, everything appears fine. But if you take a closer look, a few potential pitfalls come into focus. Take Angular Material, for instance, which is maintained by the Angular team itself. It’s expected to follow best practices, yet each UI component ships with its own NgModule. The reasoning is sound: it lets you import a single component without pulling in the entire library, which would otherwise bloat the bundle.
From a developer's perspective, however, this creates extra work. Every new component typically requires a matching NgModule, effectively forcing you to take two steps for what could be done in one. This redundancy is not just an aesthetic problem. For developers just starting out, this additional layer is often confusing. Even after years, I still find this workflow rather cumbersome.
How Vue.js Handles Component Reuse
When I first tried Vue.js, I didn't encounter the same mental overhead. Only after some time did I realize I was writing less boilerplate to achieve the same component interactions compared to Angular. Wondering why, I put the two approaches side by side. The answer eventually surfaced: modules simply weren't in the picture.
In Vue.js, everything revolves around components. Need a page? Create a component. Need a reusable UI element? You guessed it — another component. There's no extra filing system to think about. Now, one might argue that modules enforce a more structured pattern. Yet, I struggle to point out a real benefit from this added layer in my daily work.
Looking Ahead: Will Angular Drop NgModule?
Fortunately, the Angular roadmap suggests that change is on the horizon. The team has detailed a proposal in an RFC discussing standalone components, directives, and pipes, with the aim of making NgModule unnecessary for everyday tasks. That said, the official stance is worth quoting in full because it sets clear expectations.
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.
Final Thoughts
Making modules optional is the first major move toward simplifying Anguular's mental model. I see this as a pure win for developers. It's even conceivable that, down the line, Angular might adopt fully functional components rather than relying on classes, following a path similar to React — but for now, breathing room from modules is a good start.