Aurelia 2: a standards-first framework that still calls itself beta

Who Aurelia 2 is actually for

Aurelia 2 targets teams building browser, mobile and desktop applications who want the framework to stay out of the way. The README states the project focuses on aligning closely with web platform specifications, using convention over configuration, and having minimal framework intrusion. That is a design stance, not a feature list, and it shapes everything else: components are plain JavaScript or TypeScript classes paired with HTML templates, and bindings live in the template rather than in a framework-specific wrapper.

The audience is narrower than the description suggests. The README carries a note that Aurelia 2 is still in beta and that a number of features and use cases around the public API are still untested, with a few more breaking changes expected. The most recent release is v2.0.0-rc.2, published on 2026-08-04, following rc.1 on 2026-03-13 and rc.0 on 2026-01-14. So the project is not archived and the last push to master was on 2026-08-04, but it has not shipped a stable 2.0. If your organisation requires a versioned stability guarantee before writing production code, this is the wrong moment to start. If you can absorb API movement and want a framework whose templates look like HTML, the trade-off is legible.

How the monorepo is put together

This is a monorepo, not a single package. The root package.json declares npm workspaces spanning packages/kernel, packages/metadata, packages/platform, packages/platform-browser, packages/expression-parser, packages/template-compiler, packages/runtime, packages/runtime-html, packages/router, packages/router-direct, packages/validation, packages/i18n, packages/state, packages/fetch-client, packages/dialog, packages/web-components, packages/ui-virtualization, packages/compat-v1 and others. Tooling lives separately under packages-tooling: vite-plugin, webpack-loader, plugin-conventions, plugin-gulp, parcel-transformer, babel-jest and ts-jest.

That layout tells you where the boundaries are. Template compilation is a distinct package from the runtime that executes the result, and the expression parser is separate again. The router and router-direct are two packages rather than one, which suggests two routing approaches coexist. The compat-v1 package exists to bridge from Aurelia 1, though the README does not document what it covers. Build orchestration uses turbo.json, and the root declares packageManager [email protected], so the repository itself expects npm 10.9.0.

The bindings shown in the README are the clearest signal of the framework's character. A template can write value.bind="name & debounce:500" to bind an input with a debounce modifier, repeat.for="q of quests" to iterate, if.bind to conditionally render, and ${quest.toLowerCase()} to interpolate an expression that calls a method. Those are template-level constructs, not component-level configuration, which is what minimal intrusion means in practice.

Installing Aurelia 2 and building a first component

The README requires Node.js v8.9.0 or above and directs you to npx, which ships with Node.js. From a command prompt, the documented scaffold command is:

npx makes aurelia

This downloads the makes scaffolding tool and the aurelia generator, then walks you through setup. When it finishes you have a project ready to run. If you prefer not to use the generator, the README points to the examples folder in the repository for pure JIT setups with no conventions, across various loaders and bundlers. The examples directory contains concrete starting points such as examples/helloworld, examples/1kcomponents, examples/navigation-skeleton, examples/realworld-advanced, examples/state-plugin and examples/validation-with-router.

The component model is two files. A class holds state, and a template binds to it:

//app.js
export class App {
  welcome = "Welcome to Aurelia";

  quests = [
    "To seek the holy grail",
    "To take the ring to Mordor",
    "To rescue princess Leia"
  ];
}

The matching template uses the binding syntax directly. This is the README's own example:

<!-- app.html -->
<form>
  <label>
    <span>What is your name?</span>
    <input value.bind="name & debounce:500">
  </label>

  <label>
    <span>What is your quest?</span>
    <select value.bind="quest">
      <option></option>
      <option repeat.for="q of quests">${q}</option>
    </select>
  </label>
</form>

<p if.bind="name">${welcome}, ${name}!</p>
<p if.bind="quest">Now set forth ${quest.toLowerCase()}!</p>

What you should see is a form with a debounced text input and a select populated from the quests array, plus two paragraphs that appear only once name or quest has a value. Note that the class in the first block does not declare name or quest, yet the template binds to both; the README presents the two blocks as the framework's binding demonstration rather than as a single runnable file, so treat the pair as illustrative of syntax, not as a complete app. For a full project, the scaffold from npx makes aurelia is the documented path.

Beta status is the limitation that matters most

The README is unusually direct: Aurelia 2 is still in beta, parts of the public API are untested, and more breaking changes are coming. Release candidates rc.0, rc.1 and rc.2 landed in January, March and August 2026 respectively, which is a steady cadence but not a stability promise. A team that adopts rc.2 and pins it will be fine until they need a fix that only exists on a later candidate, at which point they inherit whatever changed.

The documentation is the second constraint. The README says the new docs are a work in progress and that the most complete material is the getting started section, with the Quick Start Guide as the entry point for newcomers. That means the surface area you can read about is smaller than the surface area the monorepo ships. Packages like ui-virtualization, dialog, i18n, validation-i18n and store-v1 appear in the workspace list but the README gives no usage guidance for them. You will be reading source and examples for those.

There is also no documented rollback or upgrade guide in the README. The compat-v1 package exists in the workspace list, but the README does not explain what it migrates or how completely. If you are coming from Aurelia 1, that absence is the thing to investigate before writing code, not after.

Where Aurelia 2 differs from React and Angular

React and Angular are the obvious alternatives, and the difference is where the framework sits. React is a library for composing UI from components and functions, and you choose your own routing, state and form handling from a large ecosystem. Aurelia 2 ships router, router-direct, state, validation, validation-html, i18n, dialog, fetch-client and ui-virtualization as first-party workspace packages, so the integration surface is decided for you.

Angular is the closer comparison in scope, since it also bundles routing, forms and dependency injection. The split is philosophical. Angular templates carry framework-specific syntax and the framework owns more of the component lifecycle. Aurelia 2's stated position is convention over configuration and minimal framework intrusion, and the binding syntax in the README reflects that: value.bind, repeat.for, if.bind and string interpolation that accepts method calls like ${quest.toLowerCase()}. If you have written Angular templates, the constructs will look familiar; the difference is how much of the application the framework expects to own.

There is a cost to the Aurelia 2 position. A smaller first-party ecosystem means fewer ready-made integrations, and the beta label means less community-written material to fall back on when the docs are thin. The monorepo's examples folder, with entries from helloworld through realworld-advanced, is doing a lot of the teaching that a mature framework would put in guides.

Licence, maintenance and what an upgrade costs

Aurelia is MIT licensed, per the README and the LICENSE file at the repository root. That permits commercial use, modification and redistribution with the licence and copyright notice retained. It does not include a patent grant, which some corporate legal teams look for; that is a question for your own counsel, not something the repository answers.

Maintenance signals are mixed. The repository is not archived and the last push was on 2026-08-04, the same date as the rc.2 release, so work is landing. The version in the root package.json is 2.0.0-rc.2, matching the release tag. The presence of a .changeset directory indicates changesets are used to record changes between releases, which is where you would look for breaking-change notes when moving from rc.1 to rc.2. The README does not describe a support window, a deprecation policy or an LTS branch, so an upgrade plan has to be built from the changesets and the release tags themselves.

The practical upgrade cost is the monorepo structure. Because the framework is split across many workspace packages, upgrading means moving several packages in step, and the tooling packages (vite-plugin, webpack-loader, plugin-conventions) version alongside them. The repository also carries a substantial test layout, with e2e suites numbered through at least 16 covering HMR, i18n, router-direct, validation and type checking, which is a sign the maintainers test integration paths rather than only units.

Editorial conclusion

Aurelia 2 suits teams that want convention-driven components and are comfortable pinning a release candidate while the public API settles. Teams that need a stable, long-term API today should not adopt it, and neither should anyone who needs documented migration tooling, since the README points to the compat-v1 package but does not describe a migration path. Before committing, verify which packages your app actually imports, check the changesets directory for breaking-change notes between rc.1 and rc.2, and confirm the release candidate status in the README is still accurate.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes