Routing in Angular — Older vs Newer Versions

Welcome to the Routing Rollercoaster. Ah, Angular routing. That magical maze where beginners get lost, veterans cry a little, and everyone eventually Googles “Angular routing best practices” at 2 a.m.

Back in the day (a.k.a. pre-Angular 14), setting up routing felt like assembling IKEA furniture with no instructions, five extra screws, and a mysterious third NgModule you didn’t even know you had. But then came Angular 14+, kicking down the door like an over-caffeinated superhero shouting- “STANDALONE COMPONENTS FOR EVERYONE!”

So, if you’ve ever felt personally victimized by RouterModule.forRoot() or wondered why your routerLink is mysteriously broken (again), buckle up — because we’re diving head-first into the glorious chaos of Angular routing: Before and After the standalone NG revolution.

1. Module Requirement for Routing

In older Angular versions, routing was tightly coupled with NgModules. You had to configure routes inside a module using RouterModule.forRoot() for root routes and RouterModule.forChild() for feature modules. This required importing and configuring routing within an NgModule, adding complexity and boilerplate. In Angular 14 and above, especially with standalone components, you can bypass NgModules altogether. Routing is configured using provideRouter() directly in main.ts, making setup more modular and intuitive.

2. Component Declaration and Structure

Traditionally, every component used in routing had to be declared in an NgModule’s declarations array. This tightly bound components to module scopes. In Angular 14+, with the introduction of standalone components (standalone: true), you no longer need to declare components in NgModules. Standalone components are self-contained and can be directly loaded in route configurations, reducing coupling and improving reusability.

3. Routing Directive Availability

In older versions, importing RouterModule into your NgModule automatically made directives like routerLink, router-outlet, and others available to all components declared in that module. However, with standalone components, you must explicitly import routing directives like RouterLink, RouterOutlet, or RouterLinkActive into the imports array of each component where they’re needed. This offers better clarity and control, though at the cost of slightly more verbose setup per component.

4. Lazy Loading of Components

Lazy loading in older Angular versions was possible only through modules. You used loadChildren to dynamically import a module and its components. In Angular 14+, lazy loading supports both modules and standalone components. You can now lazy-load a component using loadComponent, simplifying lazy loading for simpler apps or micro frontend patterns, and avoiding the need for feature modules.

5. Route Configuration and Setup

Before Angular 14, route definitions were embedded in NgModules, and routes were passed to RouterModule.forRoot() or forChild(). The newer Angular setup allows route configurations to live outside of NgModules and be passed directly to provideRouter() during application bootstrapping. This promotes better separation of concerns and enables more flexible bootstrapping strategies.

6. Bootstrapping the Application

Bootstrapping an ng app traditionally required a root NgModule (AppModule) & used platformBrowserDynamic().bootstrapModule(AppModule). With standalone components in Angular 14+, you can now use bootstrapApplication(AppComponent, { providers: [...] }) directly in main.ts, skipping the need for an NgModule entirely. This leads to quicker and simpler app initialization.

7. Tree Shaking and Bundle Size

In module-based routing (older Angular), the dependency graph was often larger and less optimal due to NgModule scoping. This could affect bundle size and tree-shaking effectiveness. The new standalone approach offers a flatter, more declarative structure, which is more tree-shakable and results in potentially smaller and more efficient builds.

8. Reusability and Modularity

Older Angular’s routing architecture made components less reusable because of their tight coupling to NgModules. With standalone components and route-level imports, each component is self-contained. This design pattern is ideal for modern architectures like micro frontends and improves code reuse across libraries or projects.

9. Learning Curve and Developer Experience

The NgModule-based routing system introduced a steeper learning curve for beginners due to the multiple steps required to wire up a component and route it. Standalone routing in Angular 14+ simplifies this by reducing boilerplate and providing a more intuitive mental model, especially for new developers or small teams.

Check out the cheat-sheet below which lists the comparison-

And there you have it — the dramatic saga of Angular routing, from the ancient scrolls of NgModules to the sleek, modern scroll-less world of standalone components.

Gone are the days of mindlessly copy-pasting RouterModule.forChild() and pretending you understood what "tree-shakable" meant. Welcome to the future, where you can bootstrap your app without a module, route without a ceremony, and maybe — just maybe — go one day without yelling “WHY IS THIS NOT RENDERING?!”

So, whether you’re a battle-hardened Angular dinosaur or a fresh-faced dev who’s never heard of AppModule, remember: the routing gods are kinder now... but they still require you to import RouterLink. Always. 🔥