Every year, someone declares Aurelia dead. Every year, they are wrong.
It is 2026 and Aurelia 2 is not just alive, it is shipping features at a pace that would make frameworks with ten times our resources jealous. We have released more updates in the last twelve months than some “stable” frameworks manage in three years. The community is building. The core team is cooking. And the developers who actually use Aurelia instead of just talking about it on social media are shipping production applications while everyone else argues about which state management library to use this week.
Let me tell you what has been happening while you were not paying attention.
The Development Cadence Is Relentless
Look at the release history. Beta 22. Beta 23. Beta 24. Beta 25. Each one packed with features, fixes, and improvements. This is not a dead project coasting on fumes. This is active, aggressive development from a team that genuinely cares about getting things right.
In 2025 alone, we shipped async computed observers, a completely rewritten dialog system using native HTML dialog elements, state middleware, a router overhaul, Single File Component support, Storybook integration, and documentation improvements that transformed our docs from adequate to genuinely excellent. We launched a new website. We started producing video tutorials. We built tooling for VS Code that actually works.
Compare that to the “stable” frameworks where the core team has moved on to the next shiny thing and maintenance mode means “we will review your PR eventually, maybe.” Aurelia 2 is under active development by people who use it every day and care deeply about making it better.
The Feature Set Is Unmatched
Let me run through what Aurelia 2 actually offers, because I do not think people appreciate just how comprehensive this framework is.
The binding system. Two-way binding that just works. No useState hooks. No reactivity gotchas. No “why did my component not re-render” debugging sessions. You bind a property, you change the property, the DOM updates. Revolutionary, I know. Other frameworks spent a decade trying to avoid two-way binding and are now awkwardly reinventing it because it turns out developers actually want their UI to stay in sync with their data.
Convention over configuration. Create a file called my-component.ts and a file called my-component.html in the same folder. Congratulations, you have a component. No boilerplate. No decorators required for basic cases. No configuration files. Aurelia figures out what you meant and does the right thing. When you need to customise, you can. When you do not, you do not have to.
Dependency injection that does not suck. Built into the framework from day one. Not bolted on as an afterthought. Not requiring a separate library. Just clean, hierarchical DI that makes testing trivial and architecture sensible. I have worked on React codebases where half the code is prop drilling or context providers. Aurelia applications do not have that problem.
A router that actually works. Not three competing routers with different philosophies. One router, well-designed, with support for child routes, parameters, guards, and everything else you need. The router-lite package has matured into the default router, and it handles complex routing scenarios without the configuration nightmares I see in other ecosystems.
First-class TypeScript support. Not an afterthought. Not “you can add types if you want.” Aurelia 2 is written in TypeScript and designed for TypeScript. The tooling understands your types. The templates are type-checked. The IDE integration actually works.
Plugins for everything. Validation. Internationalisation. State management. Dialogs. Fetch client. All official, all maintained, all designed to work together seamlessly. You are not cobbling together five different libraries from five different authors with five different philosophies and hoping they play nice.
The Developer Experience Is Unparalleled
I have built applications in React, Vue, Angular, Svelte, and Solid. I keep coming back to Aurelia because the developer experience is simply better.
There is less ceremony. A component is a class and a template. That is it. No export default defineComponent wrapper. No <script setup> magic. No learning which lifecycle hook is called when and why useEffect ran twice. You write a class with properties and methods. You write a template that uses those properties and methods. Everything else is details.
There is less fighting the framework. Aurelia stays out of your way. It does not have opinions about your folder structure. It does not care how you organise your code. It does not require you to learn a proprietary state management pattern. You write JavaScript. The framework binds it to the DOM. Done.
There is less cognitive overhead. I can context-switch into an Aurelia codebase I have not touched in months and immediately understand what is happening. The code reads like code, not like framework-specific hieroglyphics. New developers on my teams get productive in days, not weeks.
Single File Components Changed Everything
The SFC support we shipped is a game-changer for developers coming from Vue. You can now write your component class and template in a single .au file, and the Vite plugin handles the rest. It is optional, because Aurelia is about giving you choices, but for developers who prefer that workflow, it is there and it works beautifully.
This is what I love about Aurelia’s philosophy. We saw a pattern that developers liked in other frameworks. We did not dismiss it as “not the Aurelia way.” We built support for it, made it integrate seamlessly with our tooling, and shipped it. That is how a framework should evolve.
The Documentation Is Actually Good Now
I am going to be honest: our documentation used to be a weak point. It was adequate but not great. That has changed dramatically.
The new docs site is comprehensive. We have a philosophy section inspired by Rails that explains not just how to use Aurelia but why it works the way it does. We have tutorials that actually walk you through building real applications. We have integration guides for GraphQL, Firebase, Tailwind, and more. We have recipes for common patterns. We have API documentation that is actually complete.
The video tutorial initiative is producing content regularly. These are not just “hello world” demos. They are deep dives into real patterns and use cases, the kind of content that actually helps developers level up.
If you tried Aurelia before and bounced off the docs, try again. It is a different experience now.
The Community Is Stronger Than You Think
The Aurelia community is not the largest, but it might be the most dedicated. These are developers who chose Aurelia deliberately, who understand its philosophy, who appreciate what makes it different. They are not here because Aurelia was the default choice or because it was trending on Twitter. They are here because they evaluated the options and decided Aurelia was best.
The Discord is active with real conversations, not just help vampires asking the same questions. The forums have substantive discussions about architecture and patterns. When someone files an issue on GitHub, it gets attention from core team members who actually care about fixing it.
There are companies running Aurelia in production at scale. Enterprise applications handling real money and real users. These are not toy projects or weekend experiments. Aurelia has proven itself in the environments that matter.
We Are Building for the Long Term
Here is what separates Aurelia from the JavaScript flavour of the month: we are not chasing hype. We are not pivoting our entire architecture every eighteen months because someone wrote a blog post about a new rendering technique. We are not deprecating APIs that developers depend on because we got bored and wanted to try something new.
Aurelia 1 applications from 2016 still work. The upgrade path to Aurelia 2 preserves most of your knowledge and much of your code. We respect our users’ investment. We understand that developers choose a framework because they want to build applications, not because they want to rewrite their applications every two years to keep up with breaking changes.
This stability is a feature, not a bug. When you build on Aurelia, you are building on something that will still be here and still be supported years from now. Can the hot new framework say the same? History suggests otherwise.
What Is Coming Next
The roadmap is clear and we are executing on it.
The observation system improvements in recent betas have laid the groundwork for even better performance and developer experience. Async computed observers open up patterns that were previously awkward or impossible. The native dialog integration modernises one of the most common UI patterns.
The tooling continues to improve. The VS Code extension gets smarter with every release. The Vite integration is rock solid. The debugging experience is better than ever.
We are working toward a release candidate and stable release, and this time the path is clear. The core is solid. The plugins are mature. The documentation is comprehensive. The remaining work is stabilisation and polish, not fundamental architecture changes.
Stop Sleeping on Aurelia
I am tired of watching developers choose objectively worse frameworks because they saw more tweets about them. I am tired of the assumption that popularity equals quality. I am tired of Aurelia being dismissed by people who have never actually tried it.
If you value developer experience over hype, try Aurelia. If you want conventions that make sense instead of configuration that makes your head hurt, try Aurelia. If you want a framework that will still be here and still be supported in five years, try Aurelia. If you want to actually build your application instead of fighting your tools, try Aurelia.
The framework that refused to die is not just surviving. It is thriving. And 2026 is going to be the year everyone else finally notices.
Come build something with us.