Angular: does NgModules will be optional?

SafeValue must use [property]=binding: Angular developer's team is seriously considering an idea to make NgModules optional.The point is to stop that tedious creation of the NgModule to bootstrap even the simplest "Hello, World" application. Let us remind you what NgModules means in an Angular global conception. NgModules are kind of containers that includes functionality to manage dependencies in the framework at all. You don't have to directly refer to the dependence of the component, directive, pipe, or provider. You have to import NgModule full of exported components, directives, pipes, and configured providers instead. Naturally, you must create NgModule for every single simple application. A bit boring, right? The effort they put is brightly shown on the Angular discussion forum on GitHub: "RFC: Standalone components, directives, and pipes - making Angular's NgModules optional #43784" "The goal," - they clarify - "of this RFC, is to validate the design with the community, solicit feedback on open questions, and enable experimentation via a non-production-ready prototype included in this proposal." For at least a month from October 8, they have been eager to get feedback from the community regarding the Angular concept centered around NgModule. They argue that this conception is a restraining factor for the excellent user experience. Here are the points RFC (request for comment) declares:

• Creating components requires more effort than encoding a class or template:
  • you are forced to put the component into its own NgModule if you are planning to reuse it independently;
  • or you must fit it somewhere else in the application's NgModule hierarchy.
• APIs around loading and rendering are unnecessarily complex and easy to misuse.
• Reading component code is not enough to understand component behavior.
• Angular tools must deal with "implicit" dependencies of components on their NgModule context.

So what does RFC offer? Their plan is directed to simplify the "mental model" of Angular. They call us to a world where components, directives, and channels play a more critical role, are self-sufficient, and safely imported and used directly. It will make it possible to create new APIs for using components and directives, improving the Angular tool's ability to process code efficiently. So we will get the simpler, easier, terse, and faster Angular. It does not mean that the concept of the NgModule would be removed from Angular. It only means that you can use it at your discretion for the typical development tasks. Also, it will not be considered deprecated or even will disappear at all, but the Angular development team could consider removing NgModules altogether. No one encroaches on the programming freedom of developers who can still use it. You can leave your comments till November 8. Certainly, your opinion is important, and it is possible it will play a decisive role in choosing the further path of development of the framework. Anyway, just as focusing on Ivy in Angular 12 allows us to predict the trend of Angular 13, we can assume the trend of Angular 14. It looks like the next Angular 14 will surprise us a lot. (see http://g.co/ng/security#xss)