Let’s acknowledge the elephant in the room, if you’re a reader of my blog then you would know that I am a huge Aurelia fan and user. I’ve been working with Aurelia since February 2015, so 3.5 years now (wow).
I am on the Aurelia core team, I have contributed to the community through plugins/skeletons, answering questions on StackOverflow and I regularly do Aurelia consulting/freelance work (hire me). There is a good chance you’re reading this blog post because you’re familiar with my many previous Aurelia blog posts over the years.
Now we’ve got that stuff out of the way, I want to talk about why I continue to use Aurelia in the face of other choices.
Do you only use Aurelia?
No. It might surprise readers of my blog to know that I don’t always exclusively use Aurelia. Before Aurelia, I worked with ReactJS as well as Angular 1.x.
Since 2015 I have worked with React, Ember, Angular and Vue.js. In fact, about a year ago I launched a side project idea I had which is built using Vue + VueX called TidyFork. It allows you to clean up old Github forks and starred repositories.
A few months ago I helped a client migrate an Angular project over to Aurelia and it was an absolute breeze. I also participated in an internal effort to rewrite a React dashboard over to Aurelia.
In spite of not intentionally shunning other choices, I always come back to Aurelia.
Conventions
This is one of my favourite things about Aurelia and honestly, it surprises me that no other framework or library has really leveraged the convention over configuration approach. Specifically, in Angular, the use of decorators are promoted heavily and it results in overly verbose looking view-models.
Maybe it’s more of a personal preference thing, but I hate typing. I am always trying to find ways to macro my workflow and automate it. I really hate typing, especially the same thing over and over again.
If I want to create a custom element or attribute in Aurelia, all I do is name my view-model accordingly: MySpecialCustomElement or MySpecialCustomAttribute and I know Aurelia will look for the CustomElement and CustomAttribute parts to determine what kind of component this is.
I like the fact that I do not have to tell Aurelia the name of my accompanying view .html file and that it will just look for a file of the same name with the .html extension, but provide me with the option with telling Aurelia the name (if conventions can’t find it).
And the cool thing about conventions is that they can be changed. You can have the best of both worlds, let Aurelia make assumptions or tell Aurelia how you want it to work through decorators or class properties.
Reactive Binding (vDOM not included)
I’ve worked with React and Vue, I am quite familiar with the concept of a Virtual DOM and let me tell you, the Virtual DOM really irks me when people see it as a silver bullet for performance.
Aurelia doesn’t have a Virtual DOM and you probably wouldn’t even notice a difference if you compared two identical apps side-by-side (one built with React and the other Aurelia) because the reactive binding system offers many of the same benefits.
Look, there are definitely instances where Virtual DOM can be fast and it’s not slow. However, in most cases a reactive approach to binding is practically the same, it’s working with the DOM at isolated targeted points.
Be smart, don’t buy into the hype that Virtual DOM is the one true path to performance world.
Small Learning Curve
All frameworks and libraries I’ve used have boasted about their small learning curves when in reality it’s subjective and dependent on the developers skill-level and ability to learn new things.
I have first-hand experience with upskilling front-end and full-stack developers with ranging backgrounds. I have upskilled full-stack developers with no framework/library experience and developers with experience of frameworks like Angular or libraries like jQuery.
Every developer I have upskilled has grasped the basics of Aurelia within a couple of days, and that is being somewhat hands-off. The hardest part developers face is how to structure their applications and what to name things (which isn’t an Aurelia problem).
This is where the benefit of conventions come into play. If the framework makes decisions for you, there is less to learn upfront to start being productive.
You don’t need to hire “Aurelia developers”
This is one thing that really irks me about other frameworks and libraries, they make you buy into their way of doing things. React has its JSX syntax, Vue has its single-file components and Angular-like syntax. This leads companies to hiring framework and library-specific developers, I’m sure you’ve seen a job listing for a React developer before.
I’ve seen companies say they’re trying to hire Aurelia developers when Aurelia is so un-framework like all you need to do is hire a competent front-end/Javascript developer who will work out how to work with Aurelia in a day or two, easily.
Yes, Aurelia still has a little bit of buy-in with its templating language, but even that tries to follow a convention-like intuitive approach, tapping into that HTML/Javascript muscle of your brain.
Small, but passionate community
In my experience, most open source communities are hostile and/or toxic. While Aurelia has an acknowledged smaller community, it has a community and people are always around in the public chat (including Aurelia core team members). How many open source projects allow you to interact with the team building it? Not many.
Don’t buy into the FUD that Aurelia has a nonexistent community, we are here.
Unconditionally open source
After the ReactJS patents and the licencing fiasco that tainted React’s image, it really highlighted just how truly open source Aurelia is. It’s a community-led effort with many of the core team besides Rob and a few other early members being invited from the community itself.
You can use Aurelia for whatever you want, without worrying about infringing on some shadow companies legal terms or losing your licence to build applications with it.
Conclusion
I think any modern choice is great and I think regardless of whether or not you choose Angular, Aurelia, React or Vue, you can’t make a bad choice.
Keep an open mind about the frameworks and libraries you use, don’t follow the crowd and be a sheep: make your own choices.
Choose what works for you, Aurelia works for me.
Pretty passionate about Aurelia as well. Have completed a ton of apps with it. The problem at our company is that training has to go through a certain process and only Angular was available. I argued that you don’t even need training, but we have people that are too lazy to learn on their own so the class was mandatory and now everything revolves around Angular. Sucks. No one knows any better because no one will try anything else.
Vue seems really close to Aurelia, so I petitioned for that as an alternative. I just took a look at Nuxt and man…Aurelia is great and all, but even I’m feeling the ecosystem surrounding Nuxt and Vue. There’s some awesome stuff here. I have no idea why Aurelia hasn’t “taken off” like the other frameworks, but I have to admit for my next project I’m going with Nuxt and not looking back anytime soon. They don’t follow the component convention but specifying them in the vue file you’re using is pretty similar to the require tag that you’d put into your templates, on top of that there’s pre-rendering, server side rendering, vuetify for components, and honestly the syntax seems really close to Aurelia with none of the junk from Angular.
I know these things can be done with Aurelia, but I tried a lot of the stuff and it’s either not maintained, not working, both, or even not fully functional. Sure I could put in the work, but this thing has everything working out of the box. It’s a pretty easy sell.