Rob Eisenberg made a comment the other day that implied that Aurelia is not taking advantage of current web standards.
Lightly edited for brevity:
the web has changed so much in the last 10 years that what I’ve got in mind (re-imagine [web development] all in terms of 2024 baseline browser capabilities, while also looking to powerful upcoming standards) can’t really be built “on top of” Aurelia
I’ve been eagerly awaiting the Aurelia 2 release but now I’m concerned that it’s going to be stale right out of the gate. Can anyone elaborate on where Aurelia isn’t following / building on 2024 standards?
This is to be expected since development on Au 2 started in 2019 and has slowed to a crawl for the last 4 years. Most other frameworks have released 2+ iterations in that time and thus have much less baggage for each new release. That keeps them on the bleeding edge of standards/ framework design philosophies. No shade to Au2, just how it is trying to compete with frameworks that have 10x the active development.
Still, it would be nice to hear from core team which parts they consider to be a bit behind current standards and browsers. Or is it perhaps about build stack?
But with the current pace of development I wouldn’t be concerned, I would be quite sure it’s going to be stale right out of the gate. As the beta is already pretty much stale (Aurelia 2 is 4 years into development) and a stable release still doesn’t seem anywhere close.
We have waited for a stable release for 3 years now, and recently we have decided to give up hope.
There’ many language features that have been released for the last few years, and likely many more years to come. Though beside the component model of web component, I don’t feel like we cannot use any features. Take element internal as an example, which probably gonna house many more features to come, can be incorporated to our components the way it’s done for web components, if we want/need to.
Also, unless it’s proven not possible, there maybe a way to “use the ideas” that other frameworks have in Aurelia, like the way we improved our observation system with track on read/proxy based observation.
I might much prefer Eisenburg’s proposal to emerge as Aurelia 3. If the migration path is not straightforward, so be it, wouldn’t be the first framework brave enough to take such a path to improve on their prior work, and maintain viability and excitement about their product and its marketing position.
Both seem to be vaporware right now, but holding out hope for Au2 so we can eventually port Au1 projects and get some bundle size improvements because Au1+Webpack with our projects doesn’t work sadly. For everything new, we’re starting with Vue3 and it’s been great so far; simple API, great performance, great tooling, etc.
I’m not entirely up-to-date with Rob’s latest pursuits, but I know that when he discusses modern web standards, his perspective comes from his deep experience with Web Components. You might recall Rob’s significant contributions as a developer advocate for Web Components during his time at Microsoft working on Fast. From what I gather, his new projects also revolve around Web Components.
Now, let’s address Aurelia 2. It’s not “stale” or incapable of supporting modern web features. In fact, one of Aurelia’s strengths is its minimal abstractions. It doesn’t use a virtual DOM or introduce unnecessary layers that complicate working with native browser APIs. That’s why you can seamlessly integrate something like jQuery into an Aurelia app and initialize it from the attached lifecycle hook—Aurelia doesn’t impose artificial restrictions or force its own versions of web standards.
It’s also worth noting that while Aurelia 2 doesn’t yet carry the “stable” tag, the framework is extremely stable in practice. I’ve been shipping Aurelia 2 applications for years and only touch Aurelia 1 for legacy projects. If you’re comfortable keeping up with its release cycle—which, for the most part, has been smooth—Aurelia 2 is an excellent choice. The only release that posed real friction was a few betas ago, when the switch to the modern decorators’ standard broke some things due to significant changes in the proposal Aurelia was initially built upon.
We understand it’s been a long road to get here. Unlike projects backed by corporations like Microsoft or Vercel, Aurelia doesn’t have the luxury of massive funding or dedicated developer resources. Given the constraints, the progress made by our small but dedicated team has been remarkable. It may be slow, but it’s deliberate, and the results speak for themselves.
Aurelia’s most underrated strength is that the core team actively uses what they build. Every team member works with Aurelia in their day jobs, startups, or consulting projects. We’re dogfooding the framework daily, which ensures that what we’re building is practical, reliable, and battle-tested. That level of ownership and real-world usage means a lot.
I went through Rob’s Web Components Engeneering course and related material (blog posts, resources links referenced in the course).
There are a few general topics that popped out for me:
He is advocated standardization of JavaScript signals, to solve data binding on the platform level: signal-polyfill. Blog post is here. There are already libraries trying to integrate this: @lit-labs/signals
Latest standards for JavaScript imports (e.g. with { type: "css" };)
Then, there all Web Components specific topis: shadow dom isolation, even retargeting, declarative shadow dom, integration with forms, publishing of design systems based on web components and integration with other tools (Figma, Storybook), etc… Maybe here he sees some issue with current Aurelia 2 approach vs what he has in mind.
However, some of this topics are bleeding edge, I don’t think any framework currently support this approaches.
, could be totally wrong though.