Why Aurelia Struggles to Gain Popularity

**elitemike** · January 11, 2019, 2:19pm

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.

**jwx** · January 12, 2019, 1:13am

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.

**timfish** · January 13, 2019, 4:23am

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!

**jeffgrann** · January 13, 2019, 5:20pm

From my experience, I highly doubt it.

**ah1508** · February 4, 2019, 9:08am

If I may… I have used Aurelia for a few years, and regarding the entry barrier I would say that :

indeed the script tag make the first steps easier. It is also better when you want to show Aurelia to someone : “Let me show you Aurelia, you will see it is easy”. To me the cli is the opposite. “you will see it is easy but you need a special tool to get it run” is not something everyone wants to hear. I don’t like when a tool pretends to be easy but encourages to use its own build tool. The time to understand how it works and how to customize it could be used to simply understand the basics of webpack and npm.
for real world projects, the skeletons should be promoted as an alternative to CLI. skeleton-typescript-webpack exists but is it up to date ? It could also be simpler : no bootstrap, no jquery, maybe not even test. But minification, one of the first thing I check with a skeleton is the size of the bundle I get if a execute npm run-script build. Only code that someone who barely knows webpack can understand. The package.json could also be reduced to the minimum required to execute npm start and npm run-script build.

And all the time spent by the team on the CLI could be spent on something else.

In the Java world for instance, a very popular project is Spring Boot. Powerful and simple, and they choose to promote skeleton to quickly get something that works and without hiding the Maven file (Maven is the tool you need to configure your dependencies and your build process). Check start.spring.io to have an idea.

Since it is a cohesive framework and not only a library, the welcome page could promote the main features : binding, routing, publish/subscribe, property observers, state management, server side rendering… (not a full list, just enough to show how Aurelia is cohesive and complete).

Another key point is how Aurelia is non invasive. 90-95% of the code is not tight to Aurelia. To quote Spring framework again : “design is more important than any implementation technology” and “Your application code should not depend on Spring APIs”. In an ecosystem like Javascript where nobody knows which technology will be used in 5 years, it is important to have a codebase which is not tight too much to a given technology.

Motivation
One line bullet points for features,
One line bullet points for tooling integration (debuggers, webpack, tests).
numbers (something like “1 dependency”, "?? Kb minified).
sample code with the aurelia-script,
skeleton generator

could be an idea for the welcome page.

**ArchEnemy** · February 9, 2019, 3:29am

Based on my decade+ corporate experience (including recruiting a lot of engineers and grilling them for technical interrogation):

Someone said it above: finding “fully experienced enterprise devs is hard enough” period.
Corporations that recruit for specific frontend frameworks are doing it wrong. They should be recruiting for ES6 engineers. (or Typescript engineers). I don’t say developer because this isn’t real estate.
Aurelia is incredible for corporations because it doesn’t force you to learn a ton of mumbo-jumbo React syntax, Angular syntax or Vue syntax objects. It just says “create your ES6 class” okay good, put some bindings, okay great it all works, fetch some ajax, great… Eloquence and simplicity is king.
(ancedotal) Top software architects in various companies that I talk to agree on Aurelia, they like its intuitive nature and have used a number of competitors. It’s exactly what Einstein has always recommended even when coming up with a scientific theory (paraphrasing): [it must be simple and eloquent, if it’s too complex it probably isn’t a fitting theory.] Same can be applied to API designs.
Please if the Aurelia team decides to release the new version please make sure the migration guide is super simple and all “breaking changes” are super well documented (even making sure to write the version number above every “block” of code in ANY tutorial/guide). Stability is also loved (which I like Eisenberg’s point about React changing things around constantly being a bad thing).
Do not succumb to what’s popular solely because it’s popular (what was that volvo commercial recently?) but instead follow what looks like excellence. I say this for both designers-of-APIs/frameworks and for engineers who are deciding on what API/Framework to use.

One more note: Someone mentioned Spring above and I started laughing, do not follow Spring’s example, they are the exact kind of designer who overcomplicates everything and creates “magical hooks, bizarre code-conventions, and magic beans that hook into things (especially Spring Boot).” Spring does however, have a good website with generators (generators-on-the-website are what made Bootstrap very popular).

It is easy to win the framework wars, so long as the framework makes sense when you read the code like as if it’s plain English and self-evidently intuitive (and the only other part of the formula is time-for-adopt and marketing). Write beautiful code and they will come.

**jsobell** · February 11, 2019, 6:34am

I know I’m a little late to the party, but what @GraceQuirrel says is 100% appropriate.

Strong JavaScript developers (or ‘gurus’) live in a different world to corporates. The organisations that employ them are not typical organisations, and I think if they were asked to work in many of those companies they would either hastily leave or slide into a pit of despair. Management that appreciates strong innovative skills and encourages radical solution thinking are extremely rare.

Most organisations are extremely boring places to work, and typically have development skills that I would rate 3/10. Last week we were demonstrating Aurelia apps to a huge financial organisation, and their developers were asking me how to inject business login in their DTOs, and explaining that they couldn’t convert their existing apps to Aurelia or Angular because they included JQuery.

If we look at each point in turn:

Management always want a developer with more years experience than the product has existed for. They were asking for five years of Angular 2, not because they need that impossible skill-set, but because they abhor risk. The risk with a new developer or new technology is that they invest 12 months into something that is beyond the abilities of their developers, or that ceases to exist.
I think React is pretty crap, but it’s a brave IT manager who would go out there and recommend Aurelia over React. It’s also a brave developer that would approach his manager and suggest Aurelia over React, because if anything went wrong he would be crucified for his bad decision.
developers want to follow the money, and at the moment that’s Angular v27.3 (or whatever ridiculous number they’re up to). React and Angular jobs outnumber Aurelia by a factor of at least 1000, so if they can get free training in their company, they are more desirable when they want to change jobs.
It doesn’t matter what we say about the V-Next version being compatible. If it’s version x.0 of anything it will be considered unstable. For the relatively uneducated out there (which is 99.9% of management) any new technology is a huge risk, and why gamble your annual bonus on something that is not mainstream?

I love Aurelia. I’m far less keen on Angular, and I strongly dislike React.
When I went into the company on Friday, I was asked to give recommendations for things like an ORM, a webAPI technology, and… an SPA environment. Now that’s tricky, because they are clearly not skilled developers, and unless they have me or Binh there they will most likely flounder with Angular or Aurelia, but at least with Angular they would have thousands of resources online to make mistakes from, and hundreds of thousands of poor opinions on the forums.
If we end going in there we will use Aurelia, but only because we will retain control of all development.

I think this is what @GraceQuirrel was referring to, and as much as I hate the situation, I think Aurelia is the Betamax of the video-tape war (if anyone else here is old enough to remember that!).
It’s a far better technology, better designed, better developed, more responsive to issues (by a factor of 1000), and has everything nicely integrated into the core, but as the title of this whole thread says, “Why Aurelia Struggles to Gain Popularity” is primarily due to lower adoption because of the reasons above.

All the points about choosing developers on something other than framework skills are completely valid. Rob’s comments about choosing teams in Microsoft are valid too. Unfortunately most organisations are not 90% tech oriented like Microsoft, and most managers don’t appreciate true skills over claimed experience.

So going back to basics, I don’t know how to fix all this. I still feel that if much of this had been addressed three years ago (when Angular 1 was a complete shemozzle) we would all be in a far stronger situation now, but this is just how it is. Perhaps we need to get Oracle or someone to adopt Aurelia as it’s product, then every Java and Oracle DB house will consider it a fully fledged option, and it could spread from there.

Anyway, just my experience and opinion.

**CRL** · February 11, 2019, 7:38am

So I like the codesandbox.io , or at least the idea of it, but I have to say it feels a little clunky and overall I just like stackblitz.com a lot better. I mean it’s online VS CODE what’s not to love.

When I click https://stackblitz.com/ I should see a big Aurelia button there as well, allowing me to start a blank aurelia project.

If we have samples on codesandbox, they should be in stackblitz as well. If we don’t want to maintain two different sandbox technologies, I’m all for moving completely to stackblitz.com IMHO

**bigopon** · February 11, 2019, 8:22am

I used to create all examples in Stackblitz, and they all worked quite well. Until Stackblitz decided to change internal working and the examples started to break. After that they seemed to go through few big changes, so it would be wiser to use codesandbox.io as a stable platform where we can develop on.
About speed, I kind of agree, that’s also the reason why I originally liked Stackblitz much more.

Though Codesandbox has a shiny feature: a static template – no bundler / loader from Codesandbox involved. It basically just you and a webserver in your browser (I’m just using some analogy, because it behaves like one, I’m not 100% sure). That feature matches exactly the need of aurelia-script / Aurelia: very simple stuff needed.

**jsobell** · February 11, 2019, 11:22am

I think we’re drifting off-topic

I wonder if one of the approaches is to start ‘flooding’ the web with targeted real-world comparisons.
Every time we see a sample posted such as

<div class="row" *ngIf="condition; else elseRef">
	<span>Something</span>
</div>
<div class="row" *#elseRef>
	<span>Something else</span>
</div>

which is a truly awful syntax, we post a response innocently commenting that in Aurelia it’s as simple as

<div if.bind="condition" class="row">
  <span>Something</span>
</div>
<div else class="row">
    <span>Something else</span>
</div>

Looking at features such as accessing an element by ref, important for third-party integrations, and it’s painful in Angular. There are dozens of this type of thing, binding syntax for css and class definitions, dependency injection, and things like custom element resolution.

I’m trying to think of ways that intrusions can be made into the mainstream Angular and React world. By not boasting about things like performance (which most businesses don’t care about until a project is being deployed), but by pushing instead about the ease of development and second-to-none debugging experience (cough), this might be a good way of increasing adoption and even migration from those struggling with Angular 2-9.
We’d need blog entries writing, and CodeProject disruptive articles based around “Angular is not the only option…”.
Likewise with React. Perhaps comparisons between simple coding tasks in React vs Aurelia, demonstrating the advantages of separating code from templates.

Again, the important thing would be to not look like try-hards peddling a half-baked system, but demonstrating that it’s a genuine enterprise level framework. Playing on the fact that Aurelia is remarkably similar to Angular, just better, I think would be a good approach. The fact there are fundamental differences is unimportant to most devs, and as truly awful as it may sound, it might be worth offering an optional Angular template syntax as standard in the core libraries just to imply a high level of ‘compatibility’.

We have a hugely complex Aurelia app, with workflows, embedded Monaco editors, virtual grids, dialogs, etc. that could be showcased as a commercial application.

**brandonseydel** · February 11, 2019, 12:20pm

The team will be working on a comparison between frameworks coming soon. The way this will work is you will have Aurelia on the left and a list of other frameworks on the right. We will have a static list of examples that one could toggle through to compare the exact same solution in both frameworks, maybe even more than one simultaneously. Similar to your post above showing the if else statement. This would even include some large rendering and shuffling of lists to show that Aurelia is blazing fast. This will show the true power of Aurelia and the lack of “framework” littered throughout your project. Unlike other frameworks Aurelia has more of a decoupled design by nature. When people realize they are just writing ES6/Typescript classes and everything works as intended with no gotchas, the aha moment will occur. I don’t know if this site will go vCurrent or vNext, but the syntax is similar enough I would like to see vCurrent right away and then have a left toggle of vCurrent/vNext on one side and competitors on the right.

**CRL** · February 11, 2019, 7:32pm

Thanks for the reply. If there are problems running Aurelia on stackblitz, then this says more about Aurelia than stackblitz. (however I don’t think this should be the case, and we should have an Aurelia stack available, and we should have a big button on the front page) Either way, if we are going to “prefer” codesandbox.io, that’s fine, but we should NOT be leaving behind stackblitz (and others like it).

As a front-end developer, the more places I go and I see Aurelia (right up front like I see Angular), the more it will help Aurelia gain popularity with the general population. I think there needs to be a dedicated effort to have Aurelia sit side-by-side Angular on all of these sites, not just stackblitz.com

**jsobell** · February 12, 2019, 12:32am

Let’s separate performance from functionality. I wouldn’t want to see an example of the nice else syntax in the midst of 200 lines of super-fast virtual list sorting code. That mixes the message of simplicity and usability with that of complexity.
As I mentioned earlier, the cheat-sheet was an absolutely awesome source of assistance. I pushed and pushed for a moderated forum system like this about three years ago, to capture the enormous sample and advice knowledge-base that so many people were giving in the Gitter channel and collate that into an FAQ style repository, but it just didn’t happen. I suspect that is now part of our acceptability issue.

Perhaps a sensible thing would be to have a simple app with hundreds or thousands of snippets. I search for “binding” and see a list on the left with one-way, two-way, custom, properties, ref, etc. and clicking on one shows a simple code snippet on the right. Not a huge project, just a snippet like we have in the cheat-sheet.
As with any advanced framework, it’s too difficult to search through thousands of pages of doco to find a basic feature, and let’s be honest, when people do a Google search for “Aurelia accessing a DOM element”, the first match is a Stack Overflow answer, and the second a link to a 404 page error on the official doco.
Very few searches expose the official documentation, and the search feature in the doco pages on the hub is no Google.
We have the option to include a link to GistRun (or whatever the current monthly favourite sandbox environment is), but that’s not essential for most snippets. I think the key thing is to create a set of examples that are a pyramid of complexity, with five hundred really simple snippets of one or two lines, and a decreasing number of more complex examples for people to move up to as their skills improve and requirements are realised.

**CRL** · February 12, 2019, 5:59am

I think @jsobell is right. I’ve been using Aurelia since it was Durandal. Even having used it for so long there are times that I just need an example of functionality to “refresh my memory” so I know exactly how to use it. A google search usually takes me to stack overflow, and sometimes the answers there are out-dated.

In an ideal world, I should be able to come to the doc site, start typing what I’m looking for and like Google, immediately see headlines along with small-text showing the exact context/syntax I need on how to use or interact with any piece of the framework I have searched for.

I should be able to quickly scroll through the headlines until I see my exact use case or something that matches what I’m looking for. Once I’ve found the area I’m looking for I should be able to click to see all the various ways, starting from beginner to advanced, of achieving what I’m trying to do within this particular space.

More of an interactive cheat-sheet, that is the be-all, end-all, authoritative source for Aurelia. Always up to date and not just for syntax, but also best practices, patterns, starting from the surface and going all the way down to the low-level API usage etc. i.e. @jsobell’s thousands of snippets, where each snippet is the bare minimal example showing off the particular subject matter.

For as long as I’ve been using Aurelia, I feel like the low-level functionality (where Aurelia really hides its power) is put off and not very clear on how to really maximize the low-level bits. I.e. while the document site gives me examples of how to use or do something basic, the API side really is just for reference and doesn’t really show examples of how to interact with low-level bits constructively. (For this I would need to look into the source code and try to figure out what this piece of API actually does and when/where to use it etc… who has time for that?)

The new documentation site should be a place where the beginning user could gravitate towards simple use cases (binding/else/ref/etc), and the advanced user could learn how to use Aurelia at very low levels to achieve those really cool advanced use cases; all of it laid out in such a way that the user could snap code examples together like Lego bricks quickly achieve what we’re trying to do with Aurelia (regardless of complexity).

I think a first-class documentation site along these lines would go a long way towards increasing the popularity of Aurelia. I think opening up the low-level bits would increase community involvement. Make it easy for me as a developer to get in, get out, all the while making it super easy for me to contribute.

Along this vein, I could also see something like bootsnipp.com but for Aurelia where a user can search for and find higher-ordered components, generators, attributes, plug-ins, etc. as a way to help speed up Aurelia development. With a rich resource like this, enterprises and devs alike would flock to Aurelia.

– And why not. It’s like that old commercial for Rolaids… “How do you spell Awesome… A.U.R.E.L.I.A”

**danny** · April 28, 2019, 9:50pm

I’m a dev for an Australian government department. We currently have 90 Durandal single page apps that are used by millions of users.

I’ve been trying to convince my co-workers to move to Aurelia for years, but it is hard to fight against the mindshare of Angular. A surprisingly big issue for me has been that it is not clear that Aurelia is essentially “Durandal 3.0”. That makes it harder to sell to management.

It is also quite difficult to get Aurelia up and running within our constraints. We have a test harness for our Durandal SPAs that can launch any single SPA with one build chain. I’m currently trying to figure out the best way to structure and boostrap Aurelia SPA projects so they can reside within the same codebase (without having a seperate node_modules folder for each Aurelia SPA).

That said - Aurealias binding syntax and common sense is light years ahead of other frameworks.

**davismj** · April 29, 2019, 3:30pm

A surprisingly big issue for me has been that it is not clear that Aurelia is essentially “Durandal 3.0”. That makes it harder to sell to management.

A problem only management would have, as a quick look into some Aurelia applications would show identical code. We briefly held onto the Durandal brand, but wanted to distinguish Aurelia a separate product since we were no longer relying on third parties like knockout for core functionality, but had build core functionality from the ground up.

I’m currently trying to figure out the best way to structure and boostrap Aurelia SPA projects so they can reside within the same codebase (without having a seperate node_modules folder for each Aurelia SPA).

An issue that has more to do with modern JavaScript development than Aurelia, Angular will suffer from the same difficulties. Typically you would solve these issues at the module loader level, but with any of these tools it is possible to build a pre-built Aurelia bundle that each of your SPAs could depend on, ala a Durandal-style scripts folder. Jeremy Danyow has included some such bundles for use in gist.run demos, like this one: https://gist.run/?id=1b304bb0c6dc98b23f4a3994acc280e4

That said - Aurealias binding syntax and common sense is light years ahead of other frameworks.

We like to think we’re lightyears ahead of other frameworks by a few metrics. Additionally, we offer official enterprise support and services, which Google will never offer. Official is important here because interests are aligned: Aurelia only wins if you win. Angular consultants win so long as they get paid.

I hope this can help bring management around. If there’s anything we can do to help the cause, follow up here or reach out to one of us directly.

**Digitalman42** · May 14, 2019, 8:37pm

Speaking as someone absolutely new to Aurelia, but not JS frameworks (ExtJS?, jquery?), I would like to add that it’s super frustrating when the Quick Start leads you to an really simple error - the fact that the file name extension is wrong on the site or in the config file for Typescript. Never having used Typescript, I did not realize the error until I looked in developer tools in Chrome saw Aurelia was trying to load main.ts and not main.js (like instructed in the website).

Here’s what I found and after renaming my files, all works as expected:

I wonder how many other newbies to Aurelia and JS frameworks got super frustrated and just gave up on it? I almost did. I was heading to VueJS when I read a statement above about Aurelia using straight up ES6 or TS. That got me thinking Aurelia may win over VueJS. Sometimes it’s the little things that can make or break something. This is a little thing, a filename extension, but it caused a whole lot of frustration for me until I finally figured out the issue.

I hope this post helps some other newbie out there like me before someone fixes the website (or config file).

**EisenbergEffect** · May 15, 2019, 3:17am

Thanks for the feedback @Digitalman42 ! We apologize for the frustration. We’ve been over those tutorials so many times, I’m surprised that slipped through. I’ll get that fixed in the next docs update this week.

**EisenbergEffect** · May 15, 2019, 3:47am

A fix to the site docs has now been deployed. Thank you again for alerting us to the issue @Digitalman42.

**Digitalman42** · May 15, 2019, 7:58pm

Wow, that was fast. Thanks much!

Working fine now and I’m glad I stuck with Aurelia because it is super easy to learn and use. I’m rediscovering my love of UI after years of server-only work.