Why You Should Give Aurelia A Chance In 2017

Last updated: December 12, 2016

When it comes to frameworks and libraries, developers have never had so much choice. So understandably, it can be hard to convince a developer one option is better than the other.

Most front-end developers who have been around for at least 4 or 5 years most likely have the same backstory, going from jQuery to Angular, then possibly ReactJS shortly after.

Admittedly Aurelia isn’t supported by a mega-corp with endless troves of cash, but that doesn’t mean it isn’t worthy of being at the top. The Aurelia framework is backed by a company founded by Rob Eisenberg which funds itself through consulting, workshops and paid training materials.

Before jumping to conclusions, I implore you to give this article a read and then decide if Aurelia is right for you.

In January 2017, Aurelia will turn two

While many new faces discovered Aurelia in 2016, it might surprise you to know that Aurelia was officially announced January 26th, 2015, two years ago.

There was an alpha period, followed by a beta period and then release candidate before it went stable in mid-2016. Learning Aurelia in 2017 means you get to work with a stable framework, the best possible start.

Front-end development has a bit of a reputation for fly-by-night frameworks and libraries to disappear before they hit a version 1.0, so for Aurelia to hit v1 and then continually improve as well as add new features, that in itself is a big deal.

Standards-based

This is a huge deal, possibly more than many realise. As Javascript matures by adding in new features and API’s for us to work with, converging with other standards such as Fetch, standards are a big deal and important to the future of the web.

While libraries like React tout features like the Virtual DOM, they also come with the added baggage of promoting alternative non-standard abstractions like JSX syntax. Even the Angular 2 team wrote their own custom HTML parser, eschewing the HTML standard in their quest to enforce case sensitivity in HTML.

Aurelia heavily leans on the ECMAScript 2015 release for its core, specifically classes and module syntax (import, export, default). Custom attributes, custom elements and view-models are all classes. Also leaning on an upcoming ECMAScript 2017 feature, Aurelia utilises decorators extensively, although they’re not required.

The beautiful thing about learning a standard is if you decide to move on from Aurelia in the future, you aren’t throwing away everything you just learned, as many Angular 1.x developers experienced.

If you’re worried that learning Aurelia means you’ll get left behind or find it difficult to get a job, don’t. Aurelia is not an abstraction, it’s based on real standards. Unless you’re specifically applying for an AngularJS or React job, then the obscurity of Aurelia shouldn’t be seen as a downside, it’s actually irrelevant.

When you develop with Aurelia, you’re not learning a framework, you’re learning standards. Learning Aurelia is just learning modern Javascript.

It’s fast & lightweight

Even though Aurelia doesn’t have a Virtual DOM implementation, it has managed to outperform React in benchmarks performed. In-fact, Aurelia manages to beat out many of its competitors.

Don’t believe the hype, there are other ways to achieve the same thing as DOM-diffing (which is what the Virtual DOM is) through the use of asynchronous binding and batching changes.

Essentially Aurelia implements a reactive system in which every step is taken to ensure dirty-checking is not used and that things only happen when changes are made. Reacting to changes in terms of performance is much better than DOM-diffing, which is why Aurelia is so fast.

The overall size of Aurelia is quite small and there are options for developers to reduce the size even more by removing modules, lazy loading bundles, code splitting and more.

Convention over configuration

This might come down to personal taste, but Aurelia takes a convention over configuration approach. If you’re not sure what that means, it means by default Aurelia makes some assumptions about how you want your application to work.

In my experience, the default conventions will meet your needs nine out of ten times. However, if you yearn for more power through configuration, you can also be explicit in how you create your applications. This is a unique selling point because most frameworks/libraries go one way or the other.

Dependency Free & Modular

The Aurelia framework uses no third party dependencies. Even the polyfills Aurelia uses are in a package called “aurelia-polyfills” and every facet of the framework is broken into a separate package.

This means that Aurelia isn’t beholden to third party packages and individual release cycles and the Aurelia team can coordinate and release fixes/features to all facets without any friction.

The modular aspect of Aurelia means if you don’t want a router, don’t include the router package. If you’re not interested in the pub/sub event aggregator, don’t include it. If you’re using a different binding package, don’t use the Aurelia one.

Language/Build Agnostic

It doesn’t matter what language you write your applications in, as long as it compiles to Javascript, you can develop Aurelia applications using; Javascript (ES5, ES2015), TypeScript or even something like CoffeeScript if you wanted too.

The same thing applies to tooling. Aurelia currently supports; Jspm/System.js, RequireJS and Webpack. These can be used in combination with what flavour you write your Javascript in.

I personally use TypeScript/Webpack together for large applications and for proof of concepts/quick applications, I use the Aurelia CLI (which uses RequireJS).

A supportive community

Every framework and library has a community. While Aurelia’s community arguably pales in comparison to Angular or React, it isn’t any less passionate or helpful.

The official Aurelia Gitter channel is a great place to get help. All of the core members hang out there and routinely engage with the community. Even Rob (the man himself) can be seen answering questions and speaking with developers in the community.

How many frameworks can you name where the actual lead architect engages in conversation with the community quite actively? I don’t think this reflects on the framework itself, but rather reflects the passion of the people behind the framework.

Company backing

If the fact that Aurelia has been around for two years isn’t indication enough, Rob Eisenberg (the man behind Aurelia) started a company to support Aurelia called Blue Spire (formerly Durandal LLC). We mentioned this earlier, supported by consulting, workshops and paid training materials.

Rob has personally invested his own cash and time into Aurelia, it wouldn’t make any sense for him to just give up on it all. I actually think the fact that Rob is so personally invested in Aurelia is reassuring, you know it’s not going anywhere.

A small, but agile team

While the team behind Aurelia might be smaller than most, I see this as a positive. The whole process underpinning Aurelia; new features, bug fixes and pushing the framework forward is incredibly agile.

I have worked in both small and large workplaces and without fail, the smaller workplaces get more done in shorter timeframes than larger companies marred by bureaucracy and red tape, with more rigid processes (even the ones who claim to be agile).

I am fortunate enough to be privy to many of the details behind the scenes of Aurelia. If you could see what I see, then you’d be in awe at just how much a handful of developers working on the core Aurelia framework can get done.

Conclusion

I am not telling you to drop everything and use Aurelia or to impulsively change from Angular or React. On the contrary, you should be making informed decisions based on your needs.

All this article aims to do is the next time you’re deciding on which framework or library to use, to put Aurelia on your list and give it a chance instead of defaulting to Angular, React or Vue.

I think Aurelia is incredibly underrated and whether you decide to give it a glance in 2017 or not, I think its popularity will continue to grow as people yearn for simplicity and stability in their web applications.

We the front-end developer people, have enough to worry about as it is with volatile tooling without needing to worry about learning the latest hype.js abstraction.

I strongly believe that as more and more developers realise we have these great standards and that the instability and dark days of the web are behind us, Aurelia will become the natural choice.

Purchase Aurelia for Real World Applications over at Leanpub now

 

Dwayne

 

13 thoughts on “Why You Should Give Aurelia A Chance In 2017

  1. @Dale
    Those are the arguments that every framework gives, but not every one of them delivers. Most popular frameworks are not standards based (at least not the way aurelia is), not lightweight and require bigger amount of configuration than au requires. So at least three of those arguments are true :).

  2. Just a quick counter point for now:

    Tooling sucks ass… (sorry)

    Between Angular 2 and Aurelia, it’s a tie, but getting angular 1.x to work means including a javascript file (angular) and then it works, you can now use angular.

    With the modern way you need to jump through a lot of hoops just to start, and it inevitably involves being dependent on capabilities of your editor/ide and/or command line tools, which just should have died out ages ago (yeah, i hate linux, sorry)
    I barely know how to publish a website without uploading half the internet in npm packages (ide issue, sure) and god help you if you use any other source control than git, or use TypeScript…! (or both! (gasp!))
    (oh and spending days or months configuring a js build pipeline in gulp or grunt is also horrible)

    I have started using Aurelia, but i feel like an early adopter, and i definitely dont recommend others start using these new tools just yet.

    Oh and all documentation sucks, thats just how it is to be a developer, but the Aurelia documentation is indeed absolutely awful, so be prepared for a lot of annoying trial and error. (yes, this is common for all frameworks, but at least with angular 1.x you can likely find the solution on stackoverflow, with aurelia it is hit or miss)

  3. @Steffen

    Sounds like you’re just not interested in ECMAScript 2015 and above; IE, modern JavaScript Development.

    Those headaches you mention are well warranted but IMO very worth it to use modern JavaScript.

  4. On the contrary, I am extremely interested in modern JavaScript (even if i use TypeScript) but the problem currently is the number of things we depend on to make it work across an acceptable range of browsers.
    -and I’m not even talking about transpiling, because for typescript that works wonderfully well.

    Module loading and package managers are my real issue here, I would be much happier if i didn’t rely on an inferior package manager (npm, jspm and bower all count in this category) and if module loading was a native feature of javascript and had a halfway decent way to be configured. (jspm currently handles my config and it works, but clearly that’s stupid and brittle)

    And I have dealt with all those things, so apparently I agree that they are worth it, though to be honest I’m having trouble remembering why…

    -again to be fair these issues aren’t unique to Aurelia, and the end result is pretty good, I certainly feel like Aurelia is a reasonable framework, but hopefully the development experience of modern javascript applications are drastically improved, and you don’t have to know so damn much about a billion different technologies (which all have horrible documentation, obviously) to simply get started.

    The barrier of entry is high and the learning curve is very steep, and for the life of me i can’t understand why…

  5. @steffen

    You say counter point, and then go on to not mention anything specific to Aurelia at all, aside from spotty docs at parts. Your posts just seems like a rant against modern ECMAScript and the modern web environment (which can be valid), and I’m unsure why it was even posted on this article in the first place

  6. Fair point, this may not feel relevant to this particular post for you, but to be perfectly honest before you consider going with Aurelia, you should absolutely consider if you want the headache of modern web development and why it is worth it to you.

    You can’t do Aurelia without embracing the modern web, and if the modern web is just a giant headache in 2017, is Aurelia really worth considering then? -I feel it’s an important counter point.

  7. I will continue to advocate for Aurelia wherever I can, but I can’t find a job programming with it. Maybe I should move up to Brisbane with you mate 🙂

    Aurelia is great.

  8. Never. We are perfectly happy with our current setup based on React and Redux. We have features to ship, clients in the pipeline to bring on board, and a moderately large, battle tested codebase to grow further.

    We’re pretty much going to ignore any new framework development in the JS ecosystem for the next 2-3 years at the very least, and so should anyone who’s on a modern framework already – one that allows fast turnarounds and low overhead.

  9. It seem that is not being adopted so much after all this time, even with all good points. It was a good promise, but tools and time to deliver/fix things is making me hang on for a while before choose to start a project with aurelia.
    A simple thing like nested routes, or something else to build a menu with subitems is ignored, and other issues are beeing closed because is never a priority. Others like HMR and server side render are present in a lot of competitors and are taking a long time in aurelia to deliver. They are not essential, but the response time of team and work beeing done last months show a weakness of aurelia, the team is good but maybe not big enough to build the next generation framework before it became obsolete.
    HTTP/2, webcomponents, object.observe, jspm and other standards delays or failed expectations are not aurelia team fault. It still the best concept for a framework, my fear is if his future will be like knockout unable to Evolve because the lack of investment on is evolution.

  10. For tooling I believe that au-cli is awesome. Having generators and install/import that will automatically install using npm/yarn then add it to your compiled javascript is such a great feature. Also the features are also straight forward. Using their documentation not bothers me. It also feels natural when using/coding html and Typescript. Most of the syntax is just POJO in terms of Typescript.

  11. I’m using aurelia along with the css of Framework7 in a new project and I’m loving it, it made so much difference that I decided to share in git a little of what I’m using, it’s just a start, you can see here:
    https://fabionogueira.github.io/aurelia7/ in the future will be available via npm.

  12. Been working with Aurelia for a year now professionally. Really love it, it’s so simple and clean. On the downside however, I feel like I’m the only au developer in Europe or something. It feels like a dead framework. Really questioning the future of Aurelia and the decision choosing for Aurelia my company made a year ago.. let’s hope more people will adopt Aurelia, but I’m afraid that will never happen.

Leave a Reply

Your email address will not be published. Required fields are marked *