The Benefits of a Module-less Angular

I’m over-the-top excited about the latest RFC the Angular team dropped for standalone components, directives and pipes. This (to me) is pointing Angular more and more in the direction of a module-free paradigm. I personally could not be more excited about such a change.

However, it should be noted that when I play D&D, I am a chaotic-evil role. So BIG changes and LOUD NOISES are kind of my MO. But the way I see it, self-contained components create a more modular Angular. This means a lower barrier to entry for beginners, an easier mental model to grok of cycles and dependencies, less work on the compiler and, in the end, faster build times. Since this standalone feature is going to be optional, what do we have to lose?

Some Benefits in a Lovely Bulleted List:

• Lower point of entry: The learning journey only benefits from removing a piece of complexity.
• Faster builds: This should enable the compiler (in the future) to skip an analyzing step and speed up build times.
• Can still lazy load routes through standalone components.
• Treeshaking still works—maybe even works better? This proposal will not have a big impact with treeshakability of applications. The compiler behind the scenes is already doing the heavy lifting with modules to treeshake things. One benefit around treeshaking, though is:
       - The compiler will have less work to do, and the connections will be more obvious.
• You will be able to use both NgModule-based components and standalone ones with a zoneless approach. It is too early for implementation of this to be decided, but the two issues are unrelated. Standalone doesn’t make zoneless impossible—if anything, it will make it easier.

Some Thoughts on the RFC:

I love the questions the team asks themselves while putting together such a proposal. Having been privileged to be a part of several meetings before the RFC went public, I can testify to the care and thought they put into each part of their proposals. This questions in particular piqued my interest. Couldn’t we derive the standalone flag from the imports presence?

I would love to hear community thoughts on this point—currently, I could be swayed either way. Yes, the standalone truthiness could be easily derived from the fact “does the component include its own imports?”. However, just because shorthand is shorter, that does not always make it superior. There is the developer experience to take into consideration. Not only for new devs to simply understand “Is this component standalone?” but also for everyday developers—does it actually make standalone components faster to identify by having the semi-redundant flag there?

I think this is the core of the proposed changes and I couldn’t agree more. It would be a simpler model to teach and track, if modules were not part of the equation. At the end of the day, if you aren’t sold that standalone components will work for you, that is OK. This is proposed as an optional change and won’t force you into using it if you don’t want to. I highly encourage everyone, if you are using Angular currently or considering using it, to comment on this RFC. Make sure you include any concerns or even cheers you have for the team as they move Angular into the future. The team really does want your feedback and really will take it into consideration.