Aurelia vs. React.js: Based On Actual Use

There are tonnes of exciting things happening in the Javascript space in 2015. The two most exciting things for me are React.js by Facebook and Aurelia by Rob Eisenberg (of Durandal fame).

Even though Aurelia still has a few months before it hits beta status, developers will once again be at a crossroads as to what they should choose for their next projects when it nears release.

We already have Angular 1.x while still being supported for a while yet before 2.0 becomes the de-facto choice and people are forced to either upgrade or move on to something else, I don’t like the look of the new syntax nor other decisions made about its design.

As I previously mentioned in a prior article comparing Angular to Aurelia, I think Aurelia is more developer friendly and the way forward.

For me the two best choices right now are React.js and Aurelia (even in its alpha like form). These won’t be feature-by-feature comparisons, I have used both Aurelia and React.js extensively enough that I feel as though I can form an appropriate and fair opinion on my experience using the two in actual applications. You won’t find metrics, charts, performance benchmarks or any in-depth comparisons here.

Disclaimer: This is going to be more of an opinion based comparison than a traditional comparison with charts type article based on my experience using both on real applications. I won’t be debating the finer points, that’s your job.

Aurelia

When you have a product with Rob Eisenberg’s name attached to it, you know it is going to be good. Proving his genius on Durandal and other earlier projects as well as his brief stint on the Angular 2.0 core team before leaving to work on Aurelia full time.

Currently Aurelia is a slightly beyond alpha framework and not quite beta. Big changes are still happening, meaning if you’re looking for something almost complete and battle-tested: Aurelia might not be your cup of tea at the moment.

Having said that, I have been writing a production application using Aurelia (not deployed yet, but will be soon) and keeping up with the changes as they are released (which so far has been quite easy to do).

This application I am writing is visualisation heavy (using Snap.svg and CSS animations), has a service layer for data and API interaction/manipulation, a few third party libraries (Underscore, jQuery and Select2) via JSPM, routing (including child and parameterised) and of course: authentication.

As changes are made to Aurelia, Rob has been very public about what has changed. Thanks in part to Aurelia’s strict committing guidelines being able to generate descriptive change-logs is a core part of the framework and release process. This means changing things that have been removed or changed are quite easy to manage.

Some might not see ES6 support as an edge, but honestly it was the driving force behind my decision to use Aurelia. I came previously from an AngularJS heavy background and while it got the job done, it did so in often less-than-ideal ways that made you pull your hair out.

The use of class decoration for dependency injection and other nice parts of the framework means I spend less time configuring things and more time coding. It takes the fatigue out of building an application within an single page application framework.

The benefits of using such a relaxed framework are pretty obvious when you write your first few lines of Aurelia. You don’t have to extend anything, you don’t have to decorate your HTML with weird attributes, no strange scoping issues like you might encounter in Angular and you don’t have to organise your code in a specific way. As far as conventions go, Aurelia doesn’t make you do anything nor enforce strict conventions.

Don’t want to write ES6 code? The framework supports the likes of TypeScript and if you want, you can even write apps using ES5 code instead. If you’re happy with the defaults, you literally don’t have to do anything other than pulling down the code and start developing.

After using Aurelia first-hand for a couple of months now I can honestly say this promising framework is a breeze to work with. There are crucial missing pieces like a proper bundling solution (although Rob says it’s 50% there) and performance optimisations still to be made, but for the most part it is a pretty functional framework.

Even though Rob cautions going into production with Aurelia, given its lack of bundling and optimal performance optimisations, there is no reason why you can’t start using Aurelia now and in a couple of releases time (within the next month or so) when large breaking changes are less frequent and things are more stable you might be able to go into production (provided the bundling solution is done then).

The limitations that I have run into using Aurelia have been mostly related to JSPM, but most of the issues I have run into have been addressed in the latest release of JSPM 0.15 (at the time of writing this). As always exercise caution, but don’t let the early preview tag scare you, you would be surprised how complete Aurelia feels for something that isn’t anywhere near version 1.0.

The documentation is quite concise, although it could do with more explanation for some things. When I get the time, I will be contributing to various parts of Aurelia (including the documentation). I find myself not needing to reference the documentation as I have with Angular in the past, things just naturally make sense.

React.js

While on the surface it might not seem fair to compare Aurelia to React.js (and in part you are right), they’re both being used for the same things. I am not sure what the intent was behind React.js when it was first released, but it seems it has gone beyond just an alternative view layer to something bigger. The community have taken React and made it into a framework of sorts (once you cobble all of the needed pieces together).

Even though React.js is a fully-fledged and functionally released product without the early preview alpha tag and Aurelia is not, in their current state they are both surprisingly pretty on-par with one another. You can achieve the same tasks within both, just in different ways.

I recently got to work on a React.js application that was strictly React coupled with the Flux architecture (computer sciencey pub/sub system). Even though it ships without anything else, it is remarkable what you can actually achieve with React, a router component is crucial for actual applications and there is a react-router component which does the job quite well.

The turnaround time for the application was short, and React didn’t get in the way. This allows fluid development without worrying about configuration and dependency management. It is worth pointing out this is the approach Aurelia takes as well, proving the two aren’t too far from one another.

I would equate React components to Aurelia’s ViewModel’s. They are both quite similar in that you’re essentially using a class to define properties and methods bound to a particular view. The point-of-difference between the two is React doesn’t separate the logic from the view, meaning in React the View and ViewModel are both within the same file.

However, that’s not to say that Aurelia doesn’t allow you to achieve the same thing by rendering the View from within the ViewModel as well and forgoing a traditional View.

I think the original (and still current) intent behind React.js was not to be a competitor to the likes of Angular or Aurelia, but rather be the library that everyone uses with their SPA framework like Angular to improve performance.

So this means you can easily use React.js within Aurelia which I have done without any trouble at all and wrote about it as well. Or as mentioned, you can use React.js exclusively as your framework component and couple it with Flux.

I really like how React encourages the use of components, making you think about your application in chunks not as a whole. Some developers are not a fan of React’s inline styling. Personally I don’t have a problem with it, but I know some feel strongly about it more than others. Keep this in mind if you are considering using React for an entire project by itself or within an existing code-base.

Performance wise React has saved my bacon. In a previous project I was working on built using Angular 1.x, React was used to overcome performance limitations within Angular and its $watcher/$transclusion features. Dropping React in resulted in unprecedented performance gains when all hope was thought to be lost.

Then there is Flux: the uni-directional data flow concept that Flux promotes is a joy to use, but it does require a lot of code to setup properly if you want to implement it yourself instead of using a third-party library. Breaking out your views, actions, stores and constants can result in a lot of work getting things setup for Flux.

This is where the plethora of Flux implementation libraries come into play, but we won’t go into that.

Conclusion

You’ve been somewhat deliberately trolled by this article (my apologies). You were expecting a feature-by-feature comparison or a definitive reason to use one or the other. I am telling you that it doesn’t have to be like that. We need to eradicate the us-vs-them mentality in the Javascript framework/library arms race.

Aurelia and React.js can be used together and in doing so, it provides you with a level of power other frameworks cannot without subsequent complexity and strict convention like EmberJS.

Even though Angular 1.x is stable and works, I personally wouldn’t consider it for a new application starting today or soon. Not just because Angular 2.0 is coming, but because Angular does things a little differently and as a result it can mean bringing developers inexperienced with Angular into the fold can be a considerable time investment.

The same can be said for the other choices out there like Knockout and EmberJS, it feels like nothing comes close to React or Aurelia’s simplicity at the moment.

I would use Aurelia purely for the fact that its simplicity and power lies in its use of ES6 features like modules and classes, with polyfills added in for browsers that don’t support particular features.

If you like React, then I would consider using it within Aurelia or perhaps even forgo it and see how far you get just using Aurelia, which has a pretty smart observation system of its own even when native Object.observe() isn’t supported.

Having used both Aurelia and React.js, I don’t think I will be considering anything else anytime soon. I don’t know about you, but I am tired of having to learn new frameworks and I am tired of working with Angular as well. If you do choose one over the other, know of their limitations and assess your needs first.

I like how Aurelia provides me with components like Routing and working with an API in the form of XMLHTTPRequest’s without needing to download or write anything. Sometimes you just want to get something done quickly and the groundwork that React.js can make you perform can sometimes feel like a chore.

If performance limitations in Aurelia are currently a concern, dropping in React.js is a great intermediary step to addressing performance issues until we near a beta and version 1.0 of Aurelia. It’s great that React gives us options and workarounds prior performance limitations (like I mentioned I have encountered in Angular before).

Always appropriately benchmark your code and make decisions from there. Don’t choose to implement something if you don’t have any problems to begin with, you might save yourself some unnecessary work. The future is exciting, man.