Month: October 2025

Angular AI and debugging tools

Alain Chautard

This week, we’re using the 3-2-1 format of the newsletter. I’m posting a few essential articles to revisit, updates to know about, and one question to ponder:

Three articles to revisit:

Two quick updates:

  • Angular 21 is scheduled for the week of November 17th.
  • The Angular AI tutor is officially available! It’s an interactive AI-based tutorial that you can chat with and gives you challenges to work on.

One question to ponder:

Do you use any of the AI features recently released by the Angular team, such as the MCP server? If not, would you like me to write a few articles about AI with Angular? Please hit reply to let me know.

Server-side rendering: SSR or SSG, what’s the difference?

Alain Chautard

I’ve covered server-side rendering in the past, but recently realized that people get confused about SSR and SSG.

What’s the difference? SSR stands for Server-Side Rendering, and it does what it says: when requested, an Angular route is rendered on the server before being sent to the client as HTML syntax.

Then, the browser loads Angular’s JavaScript code, and the process of hydration starts: Angular takes over the “static” DOM built from our server and hooks its component code to it. In other words, front-end JavaScript takes over from that point on.

SSG stands for Static Site Generation, and the process is very much the same as SSR, with one significant difference: SSG is performed at build time, not at runtime. This is important for several reasons:

  1. The pre-rendered SSG pages can be generated weeks, if not months, before being displayed in a browser, which means they can display stale data. They don’t get updated after that last ng build, though Angular will take over and hydrate them on load, just like with SSR.
  2. SSG doesn’t require a Node.js server, but SSR does. The build output of SSG can be used as-is and deployed to any web server, like a regular client-side Angular app.

Now, how to choose between the two options? Well, the good news is that it doesn’t have to be the same choice for all routes. In an SSR app, a server-side router config is generated, and that file can be tweaked to do SSR, SSG, or even just client-side rendering based on the route:

The above example makes perfect sense: An about page doesn’t change between builds. It can be pre-rendered with SSG.

A profile page depends on user data, so this doesn’t make sense to pre-render at build time. SSR or client-side rendering are the two best options.

Last but not least, what if we want to pre-render routes that use parameters? We can do so by adding a list of param values to pre-render routes with the getPrerenderParams function:

The above example would have the Angular compiler pre-render the routes for /post/1/foo/3 and /post/2/bar/4 at build time.