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.
, could be totally wrong though.