Skip to content
Angular ng getting-started 4 min read

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 new on 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.

AspectLegacy webpack builderNew application builder
Builder name@angular-devkit/build-angular:browser@angular/build:application
Bundlerwebpackesbuild
Dev serverwebpack-dev-serverVite
Production buildsBaselineSignificantly faster
Dev startup / HMRSlower, full rebuildsNear-instant, on-demand
SSRSeparate builder + setupBuilt into the same builder
OutputSingle outputPathbrowser/, 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-webpack or ngx-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:application for all new projects — it is the default and the actively developed builder.
  • Use ng generate @angular/cli:use-application-builder instead of hand-editing angular.json so option renames are handled correctly.
  • Run ng add @angular/ssr rather 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>/browser and server output folders when configuring deployment, since the layout differs from the old flat output.
  • Keep the CLI and @angular/build versions aligned by running ng update as a unit, not piecemeal.
Last updated June 14, 2026
Was this helpful?