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 
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.
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.
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.
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.
could be an idea for the welcome page.
Based on my decade+ corporate experience (including recruiting a lot of engineers and grilling them for technical interrogation):
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.
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.
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
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.
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.
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.