I’m leading a new software effort that will be long term and would like thoughts/opinions on the state of Aurelia in general as well as Aurelia 2’s outlook of coming out of beta any time soon. I know that a lot of the work on aurelia is volunteer and people have jobs and families, so not trying to demand movement, just wanting feedback from other team leads/dev about starting a new project using Aurelia vs another framework. I’ve used Aurelia 1 since it’s early days around 2015 (I think it was around then). It has served me well and I think it is a super stable, easy to learn/teach client framework. Our current UI devs are familiar with Vue2. I’m having them take 1 week and evaluate Vue3, React, and Aurelia by creating a simple TODO app in each. After the week they will present a power point about pros/cons and thoughts about ease of use and features of each (I’ve asked them to rate at face value trying to ignore biases they may have for Vue). At that point we will vote on which one we like best, taking into consideration feedback from the presentations. That being said should Aurelia even be a contender here? If so, is using Aurelia 2 which is in beta a viable option or will there be disruptive changes coming?
I’m also in this boat. My earlier post about this Justifing Aurelia to myself also has a comment there about this same topic.
Currently I’m using Aurealia 1 but early on in the project so will be easy to switch and very interested to see what other’s say here.
I would also caution against putting to much weight on a todo example. It will give a good quick hands on intro but doesn’t push you into the weeds quite like a real project. It won’t really get into the areas where I think Aurelia like Angular really shine in that it is a complete framework (routing, state store, task queue, validation, internationalization, virtualization, animations etc…).
In fact, it will tend to make a more complete technology like Aurelia look more cumbersome early on.
A simple example favours a technology that is more superficial because the technology hasn’t been designed to deal with the more complicated issues that will eventually arise. It is optimized for the simple things so it can appear ‘better’ at the outset but later as the complexities are shoe horned to fit it become apparent that some of the design choices aren’t so good.
Frankly, the Vue Todo example on their website is amazing in it’s simplicity. Just some stuff in a script tag and you’re sorted . No boostrapping startup code or other files involved.
Everything is best at something but also worst at something (- Bill Buxton I think?). You need to clearly understand both cases. We are sold on the hype of what things are best for but ignore the worst.
Not to pick on Vue, but it is probably the best by far for a one pager app like a fancy contact form or adding some dynamic stuff to existing webpages. But there are compromises being made to get to this level of efficiency in a task like that. I wonder what they are? A Toyota Corolla optimises for a different thing than a Ford 150 pickup.
So I would ask:
how stable is the tech
how much integration with other tech is needed for a full solution.
Are these different items of tech from different vendors fully compatible or are there going to be some very unpleasant compromises.
does the tech adhere to standards. If not, this will lead to compromises and conflicting workarounds. eg) using markup that isn’t 100% valid html will lead to collisions with other technologies at some point.
what is the full scope of the foreseeable indented solution and how much friction will there be to integrate it all. Will it need state store, event/message bus, signalr, validation, video, picture editing. Do I need to have a specific [insertframeworkname] implementation/bridge to get the tech into my solution or can I just use the vanilla js one. For example, will a basic photo cropper I find on github just work as is, or does it need to be wrapped in [insertframeworkname] goo first?
Personally, if I worked in an digital marketing agency and needed to bling up pages all the time with a little dynamic magic then Vue would be my BFF. If I had to build a long term business app with lots of input fields on lots of forms then I would go for Aurelia - or Angular under duress
Thanks for the response, it gave me some thoughts of items to add to the TODO comparison I’m asking them to do such as at least route to another page and pass data, and import 3rd party lib (not already wrapped with bindings for selected framework) and show it being used. I read the thread you have going from a while back, and there is good info there. Honestly my only concern for Aurelia is using it and the development tools that it utilizes not getting updated, our team can update these I’m sure but it would require having someone become more familiar with the dreaded webpack etc. I don’t worry about stability too much because of how damn stable v1 has been. Again thanks for the response, it really helps ease concern to hear others actively developing with Aurelia still. It’s so simple that I can’t believe it lost to something like React or even Vue to be honest.
So my team has selected to just go with React. Unfortunately I couldn’t give a good argument to start a new large project with Aurelia as I too believe it is a dying framework (hopefully I’m proven wrong). I would like to point out from open collective that a Fred Kleuver expenses $1560 weekly from the project, but his commits have been few and far between since this past summer. I don’t know the case or circumstance, just wanted to point it out for others that may be providing financial backing/contributions in hopes that they translate to an official release.
Same problems here.
Doing a spike on a new project that is about to start shortly.
I love Aurelia 1 and the development experience I had was really great, but looking at the options:
Au 1 is not a viable option. I’m not going to even try to convince anyone (me included) to start a project using a framework that is no longer maintained (core aurelia 1 packages haven’t been updated on npm for 2-5 years now! Github doesn’t look any better, sadly)
Au 2 - been in alpha / beta for ages now. Doesn’t look good. I still decided to give it a go and doing a pre-spike of the spike now, just to have the chance of using au2 - just found out a core feature of router (link html attribute ) seems to be broken - reported on Github back in November, and no updates on this. This looks even worse.
Seriously, neither of the choices looks good. Majority of the companies I worked for, CTOs and Tech Leaders I know, would rule out Aurelia in favor of any of the “big frontend frameworks” - most of the heuristics are against it.
Yeah, that was a big driver why we decided to just go with React. It’s been around, easy to get support and find answers on SO, and less likely to have to resign if we hit a snag. I love Aurelia, but I just can’t justify it’s use on a new large project. React so far is not terrible (aside for the inability to separate ts from html). I’m not a big fan of react-router so far. I prefer a simpler router that’s not so opinionated and not doing so much behind the scenes.
React is awful, I will always prefer Au2 even with it’s beta hiccups on occasion.
And I say that as an old-time PHP developer so very familiar with how React (facebook) works and designs code.
There was a production project that switched from Au1 to React, and they are now in trouble. Issues and bugs continue (and sure you can blame the bad developers there, but all that docs/stackoverflow/chatrooms/plugins did not help them).
You’re better off with Svelte if you have real corporate/security concerns about Au2.
These days with containers, it matters less what you pick as long as it does the job. Despite efforts to learn all the various platforms, it is still uncomfortable to work with React. Another unbiased expert engineer after testing all the frameworks 11 months ago, preferred Vue (which has some similarities to Au2) over React but he hadn’t tried Svelte.
For me, Au2 works well. Yeah it doesn’t have all the bells/whistles and large massive support or pre-built plugins, but that’s fine with me as long as it’s easy to teach it to junior engineers which it is.
I agree on all counts… you won’t find much argument out of me. My problem is knowing if we will get tooling updates, and that any changes in web components or specs will be addressed. If AU2 would have been closer to release or little more active contributor community (i’m at fault here as well as I’ve submitted 0 PR, but have given financially) then I would have just dictated it upon the team because of how easy it is to use/teach. I really hate react so far. I feel they’ve taken a pretty simple idea, and over-engineered/over complicated it. I’m also very concerned about performance in the near future because of the amount of elements we will have on screen and the update frequency that will be required.
I was a big fan of Aurelia 1 and used it in many personal and corporate apps. Technically it was always solid, but the lack of ecosystem and readily available help and support via StackOverflow, youtube, blog etc made it too much of a trail to continue. While I was excited about Aurelia 2 I didn’t see any movement.
So I switched to Svelte and I haven’t looked back. There are a lot of things to like about the platform and if you liked Aurelia because you could use regular javascript everywhere then you’ll probably like svelte for the same reason.
Currently in the middle of a big Aurelia rewrite into Svelte and it’s going well. Perhaps because I’m a better developer than I was in my Aurelia days and perhaps because rewrites allow you to fix all the stuff you were unhappy with, but I genuinely think that Svelte is a great choice for former Aurelia developers.
Thanks for that input. I’ve looked at svelte and it is the framework I’ll be using on future personal work for sure if Aurelia 2 isn’t released by that time. It is the most similar to Aurelia that I’ve seen although Aurelia still has it beat in simplicity. There is also a new framework (one every week I know) called nue that is pretty interesting, but I ran into several bugs trying to use it with NodeJS 20 (its primary target runtime is bun).
. No boostrapping startup code or other files involved.