Aurelia 2 reaches release candidates: a framework that stays close to the platform

What Aurelia 2 actually solves

Aurelia 2 targets developers who want a front-end framework that does not impose a heavy runtime or a verbose configuration layer. The README describes it as a modern framework for browser, mobile, and desktop applications, with a focus on aligning closely with web platform specifications and using convention over configuration. In practice, that means you write a plain JavaScript or TypeScript class and a matching HTML template, and the framework wires them together without requiring you to register components in a central module or decorate every property. The project is aimed at ambitious applications, which suggests it is meant for large codebases where minimal framework intrusion helps maintainability. The core value is that you spend less time learning framework-specific APIs and more time writing standard web code.

The component model: plain classes plus HTML templates

The binding syntax in the README example shows the core mechanism. A component is a class with properties, and the template references those properties using special attributes. For instance, `value.bind="name & debounce:500"` binds an input value to the `name` property with a 500 millisecond debounce. The `repeat.for="q of quests"` attribute iterates over an array, and `if.bind` conditionally renders elements. This is a declarative template model, but it is not a virtual DOM approach. Aurelia 2 uses a real DOM with direct binding, which is a different strategy from React's reconciliation or Vue's virtual DOM. The framework's convention is that a component named `app` has a corresponding `app.html` template, so the file structure itself defines the component. This reduces boilerplate but also means you need to follow the naming convention strictly, or the framework will not find your template.

Getting started: the makes scaffolding tool

The README gives a single command to create a new project: `npx makes aurelia`. This command downloads the `makes` scaffolding tool and the `aurelia` generator, which interactively guides you through setup. The tool requires Node.js v8.9.0 or above, which is an old version by 2026 standards, but the underlying requirement is likely higher for the actual runtime. The README also points to an `examples` folder in the repository for pure JIT setups with no conventions, using various loaders and bundlers. That is a useful escape hatch if you do not want the generated project structure. The scaffolding approach is opinionated, but the examples folder gives you a path to set up Aurelia 2 with your own build toolchain. There is no mention of a CLI command to add a component or generate a route, so you are expected to create files manually after the initial scaffold.

Release candidate status and what it means for adoption

The repository shows three recent releases: v2.0.0-rc.0 in January 2026, v2.0.0-rc.1 in March 2026, and v2.0.0-rc.2 in August 2026. The README still contains a note that Aurelia 2 is in beta, which is inconsistent with the release candidate tags. The note says a number of features and use cases around the public API are still untested and there will be a few more breaking changes. That is a direct warning for anyone planning to adopt the framework now. A release candidate means the feature set is frozen, but the breaking changes warning suggests the API is not fully stable. The gap between rc.1 and rc.2 is about five months, which indicates a slow release cadence. For a production application, you would want to wait for the final 2.0.0 release and then check the changelog for any last-minute changes.

Limitations: where Aurelia 2 is the wrong tool

The most obvious limitation is the project's own admission that the public API is not fully tested and breaking changes are coming. That alone disqualifies it for teams that need a stable foundation for a long-lived product. Another limitation is the convention-over-configuration approach: it works well for small teams that follow the naming rules, but it can be frustrating in large codebases where developers need to look up what file maps to what component. The README does not mention any server-side rendering, state management, or routing packages, so you would need to rely on the broader Aurelia ecosystem, which is not described here. The scaffolding tool `makes` is not a standard package manager command, and it introduces an extra dependency in your toolchain. For teams that prefer a more explicit component registration or a virtual DOM for performance, Aurelia 2's direct DOM approach may not be the best fit.

Alternatives: how other frameworks differ

The most direct alternative is Aurelia 1, the previous major version, which is stable and has a larger ecosystem. The difference is that Aurelia 2 is a rewrite with a new binding engine and a different component lifecycle, so migration is not a simple upgrade. For teams that want a more popular framework, React uses a virtual DOM and a component model based on JavaScript functions or classes, with a larger community and more third-party libraries. Vue offers a similar template syntax but uses a virtual DOM and a more gradual learning curve. Svelte compiles templates to imperative code at build time, which gives a different runtime performance profile. The key difference is that Aurelia 2 stays closer to the platform by using direct DOM bindings, while React and Vue abstract away the DOM updates. If you need a framework with a proven track record in production, React or Vue are safer choices. If you want a framework that feels like standard HTML and JavaScript with minimal abstraction, Aurelia 2 is worth evaluating.

Maintenance and license considerations

The repository is MIT licensed, which means you can use it in commercial projects without paying licensing fees, but you should read the LICENSE file for the exact terms. The project is actively maintained, with the last push on the same day as the rc.2 release. The monorepo contains core and plugin packages, examples, benchmarks, and documentation, which suggests a structured development process. However, the README does not provide any information about upgrade paths between release candidates, nor does it mention a migration guide from Aurelia 1. The breaking changes warning implies that upgrading between versions may require manual work. The security policy in the README asks you to report vulnerabilities privately, which is a good sign, but there is no mention of a security advisory process or a list of known issues. For a framework at this stage, you should budget time for API churn and for adapting your code to each new release candidate.

Editorial conclusion

Aurelia 2 fits developers who value a framework that stays close to web platform specs and who are comfortable with convention over configuration. Teams already invested in the Aurelia 1 ecosystem can start evaluating the release candidates, but production adopters should wait for the final 2.0.0 and verify that all required plugins and tooling work with the current API. Those who need a larger ecosystem, a stable 1.x release, or a framework with a more declarative template syntax should look at React, Vue, or Svelte instead. Before committing, run the example projects in the repo and test your own component library against the current release candidate.

Official sources

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