I've been a developer for years and I'm used to the structure that NgModules provide for organizing features. Now that Angular is moving toward a "standalone first" approach, I feel like the architecture is becoming a bit fragmented. For those working on complex, multi-team projects, do you still find value in using modules for grouping, or have you completely switched to standalone? How do you handle dependency management across large feature sets without the central declaration of a module?
3 answers
Standalone components are definitely the future, but they don't mean you lose organization. In a project I led in late 2023, we replaced our "FeatureModules" with a directory-based structure and utilized Barrel files (index.ts) to group related standalone components. The real benefit is the tree-shaking capability; our bundle size dropped by nearly 15% because we weren't importing entire modules for just one or two components. You still have dependency management through the imports array in the component decorator, which actually makes it easier to track what each component specifically needs.
Don't you feel that the imports array in every single component becomes extremely repetitive and harder to maintain than a single module?
We switched to 100% standalone and haven't looked back. Using provideRouter and provideHttpClient in the bootstrap makes the setup much cleaner.
Christopher is right. The new bootstrapApplication API is so much more intuitive than the old platformBrowserDynamic boilerplate. It feels like modern web development.
I hear you, Kevin, but look at it this way: it increases "local reasoning." When you open a component file, you know exactly what its dependencies are without hunting through a module file that might have 50 other declarations. To avoid the repetition, we often create "Shared Arrays" of common directives (like CommonModule or Material modules) and just spread them into the imports. It keeps the code DRY while staying standalone.