Why Aurelia Struggles to Gain Popularity


One thing I’d love to see for vNext is the Aurelia team pick a loader/bundler and stick with it. I’m still not sure which is the best way to go… The ability for people to use whatever is great, but the CLI focus should be around 1 option and anything else is a use at your own risk.

Oh and a simple update path, I’m still scared to update anything in my projects so I usually create a new project and see what is all being pulled changed.


Just make everything integrated with the ability to customize if need be. All the webpack shite should be all shoved in npm packages and not to the front in the project. Then write a custom interface to override/add properties into webpack or w.e loader it may be since webpack could be gone in bout a sec the way the web moves. This interface should be rarely used. I have no problem with webpack, but trying to teach other devs makes me hate it lol. Eyes glaze over and it’s like I am hypnotizing them. Someone not understanding what I am telling them when I feel it is so simple is more frustrating than not understanding it lol :slight_smile:


webpack is like css. Once you got it, it looks very simple, then you forgot how much effort did you spend to get there.

Then you start to wonder why folks just don’t understand that to show the cut-off region of an element is simply set overflow: hidden on its parent. It’s so obvious! folks.


Management and developers in my organisation have jointly decided: our existing Aurelia apps are now legacy - all new green-field development will use React.

The main reasons - in summary:

  • Management want to be able to easily recruit developers with a history of writing non-trivial enterprise apps. If we need a team of developers next month, it is hard (impossible) to get people with a prior record of using Aurelia - the talent pool is very small. The argument that Aurelia is non-opinionated and any good JavaScript developer can pick it up does not cut it - there appear to be few skilled developers willing to abandon whatever they are currently using successfully elsewhere to learn Aurelia. It is thought that being able to recruit and retain experienced React developers who can hit the ground running will be easier.

  • Our current developers do not really want to learn or use Aurelia. This is seen as career suicide. The majority of jobs elsewhere appear to want React skills (and some others - never Aurelia). If they use Aurelia, they will become de-skilled and stuck forever maintaining legacy apps. Need to learn React to stay current. Can’t do that here, they will probably leave. And React is “cool”. Or so the argument goes.

  • The fact there is a new version of Aurelia around the corner has probably accelerated this decision. Starting any new major project with a soon-to-be replaced framework is risky. If there is going to be risk, why not go all-in and just switch to React instead?


@GraceQuirrel I have to respectfully disagree. I think looking for framework XYZ developers is the wrong way to go about it. Wouldn’t you rather look for front-end developers? Developers that have strong foundation in JavaScript / CSS / HTML? Meaning framework agnostic right?

I love Aurelia because of the fact that you do not need to know in depth the framework (as you work with it you will) but you can get started and have something awesome real quick using your JS / CSS / HTML skills…

I have built several non-trivial apps using Aurelia. Apps that are being used heavily in production. Using Aurelia allowed me to get the front-end up and running very quickly.

I know a big gripe about Aurelia is the bundling system. I have used RequiredJs and the CLI. Once I found out about aurelia-webpack-plugin, I made the switch and for me it was super simple. It did not take me more than a day and a half to get the app working with webpack (including smoke testing). Now I just stick to using webpack with the plugin.

I think if developers are willing to give Aurelia a try and see how simple it is to get a “real” app working, those developers would be amazed.

The biggest thing for me is the fact that Aurelia has maintained their braking changes minimal. Not a lot of the other frameworks can say that!



@GraceQuirrel is simply stating the facts as they are in the corporate world. I agree that this shouldn’t be the case, but it is. Companies should seek good front-end developers, not just “developers” who “know” a particular framework.

This baloney has been going on since IT began.


Well, I don’t know the internals of your company’s workings, nor have I been in the room for those conversations. But, as someone who was a decent level at Microsoft, and was a hiring manager there who built a business-critical team, and who interviews engineers of all levels at my current job as well, I’ll provide a few quick thoughts.

  • Hire people who like to learn and are good at it. If you’re hiring people who aren’t interested in learning new things, different things, web standards, etc. then you are hiring people who are not good technologists. I’d hire someone with no Aurelia experience in a heartbeat if they showed a history of, and love for learning. Someone who is good at what they do can learn any framework in a week or two. If they can’t pick up Aurelia in a couple of weeks, then maybe your bar is too low. That’s a much worse investment for the company than any technology choice.
  • Hire people who can identify the real problem and solve it the best way. People who jump to Aurelia or React or any specific tool before understanding what the real problem is, are not the people you want. If they can only do React and nothing else, that person is not a great candidate to begin with. That’s a huge red flag on a resume or during an interview. If you are hiring based solely on React experience and not looking beyond that, you’ve got a recruiting problem, in my opinion.
  • Don’t assume that Framework X developer actually knows how to build a non-trivial app just because they have that framework on their resume. I’ve worked with a lot of React developers. It might surprise some people here, but I’ve consulted on, built and hired people to work on React apps. I’ve worked with some of the best React engineers out there. They could hack React to pieces. However, almost none of them could design an app. 100% of React apps I’ve consulted or worked on were an absolute disaster of either performance, maintenance, modularity, etc. or all of the above. You might hire someone with an awesome React resume and then end up with a terrible app. I’ve seen that happen multiple times over, and in some cases the result is millions of dollars lost or serious business danger. Be careful what you assume about people with React on their resume. The market is flooded with very junior devs who learned React in some bootcamp, can buzz talk their way through a resume, but don’t actually have a clue how to build something real. It’s a searious problem.
  • Choose the right tool for the right job. I’m not going to sit here and say that Aurelia is always the right tool for every app. However, I think it’s more often a better tool than React. Each framework has strengths and weaknesses. React has some serious technical problems at scale, both for large teams and for large codebases. React looks easy to get started with, and it is. That’s one reason why there’s such a large community. But after you get into your app dev more deeply, you are in for a world of pain. Performance is a persistent problem with React. Expect to spend a huge amount of your time doing performance optimizations, especially if you use Redux. To properly address these issues in larger apps, you need people with pretty strong CS skills, not just any old dev.
  • Using or being associated with Aurelia isn’t career suicide. If you actually focus on building your career as a good software engineer, the frameworks won’t matter. I’m a Principal Engineer at the company I work for, it’s a VP-equivalent technical leadership position here. I have no public association with React at all, yet the product engineering Director and company CTO were ecstatic about hiring me to help them with their React app. That’s because I’ve spent a lot of time developing my career, resume, etc. in ways that transcend frameworks, but rather speak to my broad skills as an engineer and technical leader. So, take your current employees and provide opportunities for them to learn new things and develop themselves. Look for candidates whose resume reflect that type of experience as well.
  • Aurelia isn’t being replaced. We’ve stated publicly that we’re keeping the binding and templating languages the same. The decorators are pretty much the same. The concepts, approaches, architecture, etc. are the same. The breaking changes are mostly in things like the router, which are very easy to fix. Aside from Ember, Aurelia is the only framework that has maintained such a high degree of non-breaking changes over the years. While Aurelia may ship a new major version every 4 - 5 years, you should know that React is doing this every 4-5 months. They are also pushing changes, such as the new Hooks API, that imply drastic changes to codebases and approaches to building React apps. So, while this just looks like an incremental feature addition in React, the ramifications involve re-writing your React app. There’s likely less churn in upgrading an Aurelia app to our vNext than there would be in updating a React app to use hooks. Spend some time looking into how React has approached these types of changes. You’re about to walk into community dictated by Facebook that doesn’t have a good history of responding to their community’s requests or providing long-term stability. People follow along with React because it’s “hip”. There’s a strong cargo-cult mentality there and it’s dangerous, having led people to blindly build things in ways that are obviously foolish if you take a step back and look at the real problems. Again, I’m speaking from experience, from what I’ve seen consulting and working on React apps myself. While there are poorly written Aurelia/Durandal apps as well, even the worst I’ve seen are better than the best React apps I’ve seen. Aurelia tends to lead developers towards better architectures even if the developer doesn’t know what they are doing. Not the case with React.

As you might expect, I’ve got a lot more thoughts on this, and I’m pretty opinionated, but I’ll leave it at this for now.


Lets not punish @GraceQuirrel for stating his - or his company - opinion here. We might not agree with the arguments but that doesn’t mean they might not be right for them. What would be more of interest is to know a bit more about the details of your project/s. Are we talking mainly about simple CRUD forms and or simple webapps? Or is it something of higher complexity?

If its the first then I’d argue the framework of choice is really not important since all of todays frameworks are good for handling basic tasks and getting the job done. We’re talking here mainly about personal preference which will end up in few days difference of dev speed and reduce to nearly zero once you’ve done more than 2-3 projects. I’d also like to claim that having talented devs for such tasks is good but not absolutely mandatory. Pick somebody with basic understanding of JS and jQuery and they should be good after a few weeks if they are interested. React will have a heads-up here in the projects beginning due to massive samples and easy get-to-go plus tons of pre-made components. Simply the fact of ecosystem will beat every other competition. Thats like comparing WPF/WinForms and Qt for pure Windows based desktop apps which is a done deal.

If on the other hand your projects are more complicated, e.g I’ll use Webtestit.com as a reference, a complete IDE focused on E2E tests and the project I’m currently working on, the choice of the framework does indeed matter. Speed, flexibility and options are king here. We don’t care about any pre-made components as they likely won’t fit anyways. The few components in use - GoldenLayout and Monaco Editor - are a nightmare to configure with Webpack and shim to work decently well with React. Yeah there are basic get-started components but scratch that if you’re doing anything beyond the bare surface. I’ve looked through other JS based IDEs and none of them is using React, for a good reason. The ones I’m aware of are using vanilla JS, Mithrill and even one with Ember. Now this doesn’t account for all the fiddles like JsPlaground, Codesandbox etc I’m talking here about a full fledged app with serious challenges. And what makes complicated apps complicated is not the framework but the actual business logic and algorithms, which have nothing to do with any framework. I think this is what @EisenbergEffect wanted to accelerate on. You need good developers to turn complicated ideas into good and performant implementations. You don’t need a React or Aurelia expert since the surface of the framework will likely be very small at the end. You need good Developers, preferably with frontend-related skills.

So I’m definitely looking forward to hearing more about the type of your projects @GraceQuirrel. I’m sad we lost you and your company as Aurelia users, but I’d like to know more of the details of your projects to better understand the why.


Well said @zewa666 Thanks for stating that better than I could :slight_smile:


Sadly what @GraceQuirrel said is truth in the real world. I had to lift Aurelia on my shoulders to keep it around.

What I don’t agree with is the statement about career suicide, at some point, react will be legacy, just like everything else. If you are a job hopper, then okay, I can see it maybe being an issue. I don’t plan on leaving my job and I started a greenfield project with Aurelia as my choice for the reasons that I can have any of the weaker front end devs help out.

I was all in with Silverlight at one point, I’m still around.


I’d just like to point out - for the benefit of budding front end developers and Aurelia users - that while what @GraceQuirrel said can indeed be a truth in the real world, it’s definitely not the only truth. There are plenty of organisations and developers with the will and possibility to look beyond a specific framework as the governing skill. As many have said, to be locked in on a specific framework isn’t desirable in the long run for either organisations and developers. If you or your organisation has the possibility to put focus on the skills needed to use tools rather than the skill to use a specific tool, it will benefit you in the long run. But if that isn’t an option for you at the moment, don’t worry, you’ll still do fine. At least until whatever tool you’ve selected goes out of fashion.


Everywhere I’ve worked, developers have declared that the code-base is legacy and that something else needs to be used. Hell, I’ve even been guilty of it in my career too. Fortunately, most times the management see sense or have been burned by this before and veto the idea early on. If you were all stuck working on 15 year old Windows Forms apps then I would be a bit more sympathetic to your predicament but you’re writing front end web apps!

…easily recruit developers with a history of writing non-trivial enterprise apps… it is hard (impossible) to get people with a prior record of using Aurelia - the talent pool is very small…

It’s hard to recruit developers with a history of writing non-trivial enterprise apps… full stop/period. As Rob very eloquently put it, switching your stack will not change this, you’ll just have more mediocre developers to sift through.

You’ve stated that you already have multiple Aurelia apps so surely you have existing front end components, code and knowledge that would be essentially thrown out if you switch? Have management done due diligence and worked out that the expected gains from switching to React will overcome this (possibly huge) loss of IP?

Our current developers do not really want to learn or use Aurelia.

The sad thing is that switching stack and throwing out your existing IP at the whim of developers often results in business suicide!


From my experience, I highly doubt it.