I never said they were complicated, but they certainly are cumbersome. It is a burden to have to deal with NgModules and they slow down the process of writing code. They also make it difficult to refactor code as the existing tools aren't smart enough to tell you which imported NgModules are no longer being. This makes the process of removing dependencies and trimming bundle size slower and more troublesome than comtemporaries the simply use es modules.

I have built multiple Angular apps and libraries because I like features like dependency injection, rxjs and the flexiblity that the directive / component APIs provide. My day job however is React and it is refreshing and productive to not have to deal with all these framework specific constructs. People will 100% opt for tools that speed them up and don't get in their way.

Both Vue and Svelte are quite similar in style to Angular. The performance and ergonomics of these tools is what gets people excited to use them. I just want their to be the same level of excitement for Angular.

I think there is still a place for NgModules, I remember that one of the problems about NgModules, is that it has too many responsibilities so possibly reducing it to one special case for advanced users might be great,

Genuine Question: What features is angular behind with due to NgModules specifically, what feature does NgModules prevent angular from having that the others do?

Anyway I feel I will only really know how good/bad initiative is when we actually experiment with it.

I guess another question I want to understand better is, is there any functionality that will be completely lost if ngModules removed?

Oh wow, I love this conversation!

I remember that one of the problems about NgModules, is that it has too many responsibilities so possibly reducing it to one special case for advanced users might be great

Specifically, I think one of the biggest complexities with the design of NgModules is that they have multiple responsibilitieswith different scopes. NgModules are how we configure component templates, and in that sense they are extremely hierarchical with imports/exports defining "public" and "private" effects within a given NgModule. However, they also configure dependency injection, which is a global operation - providers in any NgModule in the application are visible toall components in the application - the same concepts of "public" and "private" don't apply (caveat: at least before lazy loaded injectors are considered).

This dual nature makes them extremely interesting as a solution, because they enable components to "just work". If you import the NgModule for a component into your application, you can use that component in your template, and any services required by the componentor its dependencies are transitively imported into your application. You don't have to think about it!

Except, actually, you do:

Genuine Question: What features is angular behind with due to NgModules specifically, what feature does NgModules prevent angular from having that the others do?

This dual nature of NgModules leaks through the APIs in a few different ways. When you set up lazy loading in your application, you quickly discover that you can't just lazily load a component. You need to load its NgModule - components can'tstand alone in Angular (yet!). If you're using the router for lazy loading a bunch of components at once, this is only mildly inconvenient. If you're trying to lazy load specific components in routes individually, it gets tedious. And if you're lazy loading without the router, you have even more responsibility: it'syour job to ensure the NgModule side of a component is accounted for when instantiating it. You need to load the NgModule, create an injector with the right parent, andthen you can create the component on top of this injector.

So to answer@tayambamwanza's excellent question, lazy loading a component individually is one of those things we can't do today, because Angular's current components aren't guaranteed to work without their NgModule in the picture. There's no way we could offer theloadComponent API from this RFC without something like standalone.

NgModules aren't a terrible API: they work, and they provide real value in large applications. But that doesn't mean we can't do better :)

NgModules aren't a terrible API:

I agree they aren't terrible. I've always been okay with NgModules as a tool for configuring the injector because its very reminiscent of how other DI solutions setup their providers (spring / dagger / guice). My first experience with Angular however was actually AngularDart which has no concept of NgModules and uses adeps array in the component metadata for specifying the compiler scope (similar to the proposal for standalone components in Angular). As a result, I've never liked how NgModules were used to configuration compiler scope and have always found it cumbersome.

In removing the requirement for using NgModules for compiler scope, I think it's natural to ask if we need NgModules at all. Is all that conceptual overhead worth it to just configure the injector? I have a hard time thinking of a case where an NgModule is better than a simple array of providers. Lazy loading of providers is all ready supported out of the box if we simply provide on a routed component. If you peel back the layers I think the value NgModules provides begins to erode.

I for one am bullish about a future where they are no longer needed.

@alxhub Thanks for explaining, never thought of that actually.

How does the new standalone apis play with ngExpressEngine (Universal)? As far as I know, it accepts a bootstrap module (ServerAppModule). Anything about that?

Yes - at least as far as the base@angular/platform-server APIs, we will support a similar standalone version ofrenderModule, that will mirror the design ofbootstrapApplication.

Why can't we have the zone options (ngZoneEventCoalescing, ngZoneRunCoalescing) in bootstrapApplication? Are they going away?

No, they're not going away. We're trying to keep the new bootstrapping API as minimal as possible for now, and consider cases likeNgZone configuration as we expand its capabilities. It may be that having these options as first class options in the bootstrap API is not the right design. We want to get the core functionality right first, and then explore these questions.

This is an interesting idea and something we've discussed before. Currently the thinking is not to do this, for a few reasons:

1. It's already possible to react to component instantiation, via thengOnInit API.
2. There would be some overhead to check forINJECTOR_INITIALIZER on every component instantiation.

But I do see the potential for better modularity - this is something we should think about.

Thx Lars for reraising this issue 😊

Definitely a good concept that may be used in the majority of lazy use-cases and reduces complexity for beginners. Nevertheless, the named exports are important to implement more advanced concepts.

reposting for better visibility:

• https://basarat.gitbook.io/typescript/main-1/defaultisbad
• https://github.com/basarat/typescript-book/blob/master/docs/tips/defaultIsBad.md
• [RFC] Avoid or "prefer not to use" default exports mui/material-ui#21862
• https://notes.webutvikling.org/default-exports/

Very interesting questions here and parts we didn't call out in the RFC explicitly (partly to avoid "details overload" and partly because we are still debating things). But here we go:

as of now, all of the styling APIs (including the default ViewEncapsulation.Emulated but also the significantly-more-useful-with-standalone-components ShadowDom) live in the platform-x packages, thus while your samples are technically standalone they're going to require importing/providing the BrowserModule, no?

Yes. If we importbootstrapApplication from platform browser then the relevant providers should be included. Also see the discussion in another question:#45554 (comment)

is the intention to port the emulation / shadow root functionality to core?

This is not part of the "standalone" effort.

regarding Zones, this RFC doesn't appear to expose a public API for triggering change detection

ApplicationRef is still this API:

constappRef=awaitbootstrapApplication(HelloWorld);//a few moments laterappRef.components[0].instance.name='Angular';appRef.tick();

But yeh, this RFC centers the idea of "bootstrap" around the "application" concept vs. "root component" concept.

This was answered in another question, see:#45554 (reply in thread)

This proposal suggests that no Angular modules are needed to lazy load a routed standalone component:

exportconstroutes:Routes=[{path:'lazy',loadComponent:()=>import('./lazy-standalone.component').then(esModule=>esModule.LazyStandaloneComponent)},];

The same goes for dynamically loaded standalone components:

@Component({template:`<button (click)="addDynamicComponent()">    Add a dynamic component  </button>`,})exportclassAppComponent{constructor(privatevcr:ViewContainerRef){}addDynamicComponent():void{this.vcr.createComponent(DynamicStandaloneComponent);}}

I think you haverender modules in mind. Hopefully, they are not needed because a standalone component has something like a localtransitive compilation scope/local component scope.

@LayZeeDK is correct - no NgModules are necessary to lazily load standalone components. That means no loading NgModules, and no render NgModules.

Good discussion on the TestBed + standalone story! We didn't cover theTestBed APIs since we didn't spend enough time to dig into all the details. We want to spend a bit more time in this area to explore and see what needs to change.

We heavily provide services in the@Component() decorator to make sure we clean up resources once destroyed. However, while unit-testing a component you always have to call.overrideComponent(AppComponent, { set: { providers: [] } }); for services in.configureTestingModule() to be used.

With the introduction of standalone components, I believe that TestBed API need's some improvement to help with mocking. I could see an API something like this being useful:

describe("AppComponent",()=>{letfixture:ComponenetFixture<AppComponent>;letcomponent:AppComponent;beforeEach(async()=>{letauthServiceStub=jasmine.createSpyObj("AuthService",["login"]);awaitTestBed.compileComponent(AppComponent,{providers:[{provide:AuthService,useValue:authServiceStub}]});fixture=TestBed.createComponent(AppComponent);component=fixture.componentInstance;});});

We can use theTestBed.configureTestingModule for standalones too.
Turns out quite useful for shallow testing.

TestBed.configureTestingModule({declarations:[MyCmp],providers: ...,schemas:[CUSTOM_ELEMENTS_SCHEMA]})TestBed.createComponent(MyCmp);

The trick here is to make sure thatMyCmp's imported providers are ignored if already defined inTestBed.configureTestingModule.

most likely,yes :)

It will only support zone-based applications. Unlike thebootstrapModule() API, there is no option to disable zones (at least initially - we will explore zone configuration in the future, as mentioned above).

Thank you for the clarification, Alex♥️

Would it be possible to callbootstrapApplication() more than once and the platform gets reused automatically? Or will that throw an error?

Would it be possible to call bootstrapApplication() more than once and the platform gets reused automatically? Or will that throw an error?

Yes, this should work just fine. That's the distinction between platform and application - the page only has one platform, but there can be many applications running on it simultaneously.

@alxhub
That sounds interesting. If an already created platform is shared automatically, then this would even be a better situation for Micro Frontends as we have now.

To sum it up,bootstrapApplication() does several things behind the covers:

• It instantiates a singleton platform w/i the same technical context (bundle or Module Federation shared dependency) and does not error on a second attempt, but uses the already created one (today it errors).
• It instantiates a new application per call w/i the singleton platform.
• It instantiates the referenced Component.

Is this correct?

// CC@manfredsteyer

@mikezks I guess if you reuse the injector, the providers will be shared.

Thanks@wilmarques.

There is one special edge case for multi version Micro Frontends with Module Federation, where we need to reuse the platform, but bootstrap a second independent app.

It seems, that this can work with the new API like today or even a bit easier.

Which package will hostbootstrapComponent?@angular/core or@angular/platform-browser and friends?

This is not yet decided. I think there is a lot of interest on the team in putting the API in@angular/core, but that may require significant refactoring / reorganization of code, and we may choose to delay this work until a future version.

WillbootstrapComponent provideDomSanitizer?

Yes - it will implicitly bring inBrowserModule and thus provide all the same services as an NgModule-based bootstrap.

Just to update everyone on our latest thinking:bootstrapApplication will be exposed from the@angular/platform-browser: so,import {bootstrapApplication} from "@angular/platform-browser". As part of this bootstrap call all the browser-related providers from theBrowserModule (ex.:DomSanitizer) will be included.

For the SSR scenarios we are going to expose therenderApplication function from@angular/platform-server.

How do you feel about the existing name of PlatformRef#bootstrapModule,@alxhub? It doesn't mentionapp orapplication.

Say in a future version, bootstrapComponent would support NoopNgZone, would bootstrapApplication still be your preferred name?

To me, "bootstrapping" in Angular means start an "application" whether by Angular module or component. Attaching a component with a life cycle to the DOM would be a different thing in which case bootstrapComponent wouldn't be a descriptive name.

The reason I prefer bootstrapComponent is the distinction from bootstrapModule, that only a component is required. "bootstrap" is a decent name but would types be able to distinguish between passing a component and passing any other class/decorated class?

How do you feel about the existing name of PlatformRef#bootstrapModule

With the general direction of makingNgModule concepts / APIs "less prominent" I think that leavingbootstrapModule goes against this goal.

"bootstrap" is a decent name but would types be able to distinguish between passing a component and passing any other class/decorated class?

Yeh, "bootstrap" is generic and "vague enough" that we side-step the whole detailed discussion of "application" vs. "root component". As you've mentioned it is a decent name and an option that is still on the table.

Would the bootstrap function's types be able to tell whether we pass a (standalone) component, an Angular module, or some other class by mistake?

@LayZeeDK at the type level, no. This is not possible in TypeScript, since there is currently no way for decorators to alter the type they're decorating. Perhaps this will change as decorators are formally added to JavaScript itself.

In that case, should we rely on the function name, that is bootstrapComponent, and/or the parameter name, that is bootstrapApplication(component)?

Yes, and we are very much interested in ways we can improve Angular Elements. A lot of these improvements, though, go beyond the specific use of NgModules, and would depend on deeper semantic changes in how elements work (for example, how elements share their "application" / zones). This is better explored as a separate effort.

@alxhub , that makes sense. Can't wait for that!

But what if we start experimenting with something similar to what was proposed for bootstrapping applications?

Maybe something like this:

// We could use `bootstrapElement` instead of `bootstrapApplication`bootstrapElement(AppComponent,{providers:[    ...importProvidersFrom(RouterModule.forRoot([…],{…})),],});

Yes, proper support for booting multiple components, using the same Injector. This will bring much of the value from micro frontends without most of their usual costs.

I haven't worked much with micro frontends personally - can you elaborate on the use case here? Do microfrontends often bootstrap multiple components at a time? Is this not possible today using theApplicationRef.bootstrap() API (dynamic bootstrap) to bootstrap additional components within the application?

The use case is having a mono-repo with multiple teams working on different "mini-apps" that can be active on the same page, at the same time. The page can be a SPA on its own or an old-fashioned MPA. The teams can work mostly in isolation from each other.
Also, the same setup, but then with each team their own repo, and a more sophisticated deploy pipeline.
This is a business solution more than a technical solution and comes with the cost of a heavier payload for the page. The perceived value is that each team can have its own velocity/freedom.

Personally, I have only tried it in lab settings and kicked it around a little bit, and its a while ago. Yes it Is possible with current tools, but there are some issues IIRC. I think@manfredsteyer can provide way more details around this as I can.

I will add a comment covering all possible Micro Frontend implications.

One scenario that would likely break is:

• Different builds with Module Federation
• Same Angular version setup during runtime
• At least two bootstrapped Standalone Components, which can not be used w/i the same Platform instance
• Today, Angular throws an error, if we instantiate more than one Platform w/i the same versionand shared Angular dependency

// CC@manfredsteyer

Thanks for CC-ing me,@SanderElias and@mikezks. You are right: In order to support all the different "flavors" of micro frontends we find in huge companies, it would be great to a) be capable of switching out ngZone and b) bootstrap several applications using the same platform (platformBrowser).

However, I understand that not all of these things can be directly supported at the beginning.@alxhub already mentioned, that there will be another initiative for dealing with Zone.js. Anyway, I think we will find ways for doing micro frontends, e. g. by sticking at least with the traditional bootstrapping and at least with one AppModule.

To put it short: If a) and b) do not hurt, e. g. by providing a parameter object with a ngZone property, it will help micro frontend folks a lot. Otherwise, they can also live with it (but won't be that happy, also b/c as all of this is straightforward in other frameworks).

I'm not sure if I would use Angular for the use case I'm going to describe.

But imagine a Design System library created using Angular Elements. If it was possible to bootstrap several components within the same project it would be possible to export each of these components as Angular Elements.

Although it's possible using the currently available options, I agree with@manfredsteyer that it isn't so straightforward as LitElement, for example.

No config object, only array of providers.

We've learned an important lesson in years of designing APIs in Angular: that just because today we can't imagine more parameters or options to a function, doesn't mean there won't ever be new things to add to an API. So now we try to future-proof these kinds of APIs using an options parameter that can be expanded as needed with new keys.

I see. Thank you for the answer, Alex.

No, this is not our intention. Mainly we don't want to turn components into a component + NgModule combination (in the sense of being an union of all capabilities of a componentand NgModule).

Technically nothing prevents us from doing so. And this is the order in which we implement things: standalone components, directives and pipes, interoperability with NgModules, injector story etc. Then moving to the APIs (that need the pieces mentioned before).