The New Application Builder
For years the Angular CLI compiled your application with a webpack-based pipeline. Starting with Angular 16 — and made the default for new projects in Angular 17 — the CLI ships a modern application builder powered by esbuild for production bundling and Vite for the development server. The result is dramatically faster builds, a far quicker dev loop, and first-class server-side rendering (SSR) and prerendering without bolting on extra tooling. This page explains what the new builder is, why it replaced webpack, and how to migrate an existing app.
What the application builder is
The builder lives in the @angular/build package and is referenced in angular.json as @angular/build:application. A single builder now handles three concerns that used to be split across separate webpack-based builders:
- Browser bundling — your client-side application, code-split and optimized with esbuild.
- Server bundling — the SSR entry point, when you opt into server rendering.
- Prerendering — static HTML generated at build time for routes you nominate.
Because one builder owns the whole pipeline, enabling SSR is a configuration change rather than a new toolchain.
{
"projects": {
"my-app": {
"architect": {
"build": {
"builder": "@angular/build:application",
"options": {
"outputPath": "dist/my-app",
"browser": "src/main.ts",
"index": "src/index.html",
"tsConfig": "tsconfig.app.json"
}
}
}
}
}
}
Tip: New apps generated with
ng newon Angular 17+ already use@angular/build:application. You only need the migration steps below if your project predates it.
Why it replaced webpack
esbuild is written in Go and compiles in parallel, so it bundles an order of magnitude faster than the JavaScript-based webpack pipeline. In development, Vite serves modules over native ESM and only transforms files on demand, which keeps cold starts and Hot Module Replacement (HMR) near-instant even as the project grows.
| Aspect | Legacy webpack builder | New application builder |
|---|---|---|
| Builder name | @angular-devkit/build-angular:browser | @angular/build:application |
| Bundler | webpack | esbuild |
| Dev server | webpack-dev-server | Vite |
| Production builds | Baseline | Significantly faster |
| Dev startup / HMR | Slower, full rebuilds | Near-instant, on-demand |
| SSR | Separate builder + setup | Built into the same builder |
| Output | Single outputPath | browser/, server/, prerendered-routes subfolders |
The new builder also produces a cleaner output structure. Instead of one flat folder, you get a browser/ directory for client assets and, when SSR is enabled, a server/ directory for the rendering entry point.
Build and serve commands
Day-to-day commands are unchanged — the CLI dispatches to whichever builder is configured.
# Fast production build with esbuild
ng build
# Vite-powered dev server with HMR
ng serve
Output:
Initial chunk files | Names | Raw size | Transfer size
main-7QO2J3KL.js | main | 198.42 kB | 55.10 kB
polyfills-LZBJRJ.js | polyfills | 34.52 kB | 11.28 kB
styles-AB12CD34.css | styles | 2.10 kB | 512 bytes
Application bundle generation complete. [1.214 seconds]
Enabling SSR
Because rendering is built in, adding SSR is a single command. It wires up a server entry point and updates angular.json for you.
ng add @angular/ssr
This generates src/main.server.ts and a server.ts Node entry point, and registers the server bundle under the same application builder. To prerender specific static routes, add a prerender option:
{
"options": {
"browser": "src/main.ts",
"server": "src/main.server.ts",
"ssr": { "entry": "server.ts" },
"prerender": true
}
}
Migrating an existing project
The CLI ships an automated migration schematic that rewrites angular.json and adjusts option names (for example, the old main becomes browser).
ng update @angular/cli
ng generate @angular/cli:use-application-builder
After running it, review angular.json and your index.html. A few legacy webpack-specific options have no esbuild equivalent and are reported during the migration.
Warning: Custom webpack configurations (via
@angular-builders/custom-webpackorngx-build-plus) are not compatible with the esbuild builder. If you rely on a custom webpack config, replace it with esbuild plugins or the builder’s native options before migrating.
Best Practices
- Prefer
@angular/build:applicationfor all new projects — it is the default and the actively developed builder. - Use
ng generate @angular/cli:use-application-builderinstead of hand-editingangular.jsonso option renames are handled correctly. - Run
ng add @angular/ssrrather than manually wiring a server, so the SSR entry points stay in sync with the builder. - Audit and remove custom webpack configs before migrating — they will not run under esbuild.
- Inspect the new
dist/<app>/browserandserveroutput folders when configuring deployment, since the layout differs from the old flat output. - Keep the CLI and
@angular/buildversions aligned by runningng updateas a unit, not piecemeal.