Aurelia vs. Angular 2:
What should I choose?

‌‌
Test your skills. Learn something new. Get help. Repeat. Start a FREE 10-Day Trial

If you’re considering adopting a Single Page Application (SPA) framework, you already know that there are many choices. There’s Angular 1, Durandal, React, Ember and Knockout, to name a few. There also two new kids on the block getting plenty of attention: Angular 2 and Aurelia. Let’s compare to the two so you can decide which one best fits your needs.

Before we get into it, it’s worth noting that Angular 1 has had a huge adoption curve over the last few years. It has a large and vibrant community -- everywhere you look there are courses, conference talks, books and articles about Angular 1. As a result, there’s a presumption that all those people will now just migrate or upgrade to Angular 2.

On the other hand, the Aurelia framework was released a couple months prior to Angular 2, and also serves as a great choice of SPA framework with a quickly growing audience. I've worked with many of the preceding frameworks and have published courses, presented at conferences and done many consulting engagements using them for real projects. And I'm now doing the same with both Angular 2 and Aurelia.

Deciding between the two can be a challenge because both frameworks are well designed and capable of meeting just about any SPA's requirements. There’s no clear "winner" if you look at both from an objective technical viewpoint. However, there are many differences, and those differences often make it easier for some customers to pick one or the other. So, let me outline some of those differences to help guide your own interests and decisions.

ECMAScript 2015 and TypeScript

Whether you think you want to go with Angular 2 or Aurelia, the biggest change you should make applies equally to both, and is decoupled from the frameworks themselves. To build a modern web client application, you need to learn ECMAScript 2015 (aka ES2015 or ES6) or TypeScript. But just learning the language syntax is not enough -- you need to learn how to set up an environment to code, build, debug and deploy that code so it runs as ES5 JavaScript in the browser (since not all features of those languages are available in all browsers).

While you could technically code against either framework using ES5, since the framework releases are transpiled to ES5 themselves, both teams strongly encourage you to use ES2015 or TypeScript. And pretty much all documentation and samples will be in one of those two languages, so you would be on your own trying to figure out how to use them with ES5 – and that doesn’t make much sense.

Angular 1 migration

If you already have an app you've built with Angular 1, you might think that migrating to Angular 2 would be the easiest. The Angular team does provide some guidance and tooling for allowing Angular 1 and 2 code to co-exist in a single logical app, even though they’ll actually run in separate execution contexts. But there’s no direct conversion path because the design patterns of Angular 2 are substantially different than Angular 1.

Aurelia also provides documentation on migrating Angular 1 code into Aurelia code. And people with Angular 1 experience may actually feel more at home with Aurelia since it’s based on the MVVM UI separation pattern, which is very similar to the client-side MVC pattern used in Angular 1. Angular 2 no longer follows a UI separation pattern, but goes with a component-centric approach reminiscent of ASP.NET Web Forms, Windows Forms, or XAML, where you have markup and code-behind that are each coupled to one another.

Framework intrusion

Angular 2 coding is a little noisier than Aurelia because Aurelia takes a strong stance on "convention over configuration", whereas Angular 2 requires explicit configuration for just about everything you do in your app. This becomes noticeable very quickly when you put your first application together with each. For a simple master-detail data page app like the one shown below, the Angular 2 version requires about 20 lines of bootstrapping declarations code (see below) to tell Angular what standard modules of the framework to pull in, what components you’ve declared in your app, and so on. 

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';

import { AppComponent } from './app.component';
import { DataRepository } from './datarepo';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule,
    FormsModule,
    HttpModule
  ],
  providers: [ DataRepository ],
  bootstrap: [AppComponent]
})
export class AppModule { }

Aurelia requires no bootstrapping configuration or root module declarations because it has conventions that assume a standard set of framework modules will be used. It also has a convention for what the initial UI component will be named that will be the root component. So, Aurelia is able to bootstrap your app with zero corresponding configuration, and the conventions of Aurelia will be sufficient for most apps.

Additionally, in Angular 2, on each component you define you must use a decorator to identify what html template and CSS that component is associated with, as well as identifying any services that you’ll inject as dependencies. Aurelia does not require corresponding configuration for its HTML or CSS because it assumes a naming convention that expects them to be found with the same name (other than file extension) and located in the same folder as the ViewModel module. Of course, any of Aurelia's conventions are overridable through configuration.

Data binding

Aurelia has a fast, efficient two-way data binding system that will feel familiar and comfortable to anyone coming from frameworks like Angular 1, Knockout and XAML platforms. Angular 2 actually has a unidirectional data binding system, where data only flows from data source objects to bound element properties in the mark up.

To accommodate data input use cases using standard input controls, there’s an ngModel directive in which you can use a combination of property binding and event handling syntax to achieve (what feels like) two-way data binding on that element's input. However, if you’re going to write any custom input elements yourself, you’ll need to add some additional non-trivial code to your custom element in order to allow the properties of it to be data bound for input, using the same syntax as ngModel. Aurelia supports two-way data binding on any property of any element with a single consistent declaration style where you just append .bind to the property in your markup, so it seems a little more straightforward and clean.

Commercial backing

Both Angular 2 and Aurelia are open source projects with a large core team and an already thriving community surrounding each. Angular 2 is led by a dedicated team at Google and used in many of its own products, so you can be confident that it’s not going to disappear any time soon. However, Google doesn’t provide any direct support services or consulting around the framework, so you’ll have to rely on the community to provide any help you need in building apps with Angular 2. But it’s probably safe to bet that a majority of the already existing Angular 1 community will move on to Angular 2. Likewise, it’s probably true that Angular 2 will have a larger ecosystem than Aurelia does, particularly in the near term.

Aurelia is backed by a small company named Blue Spire, and its entire business model is based around providing consulting services and support for applications built with Aurelia. As a result, some might have concerns about there being more risk of that company going away, but as long as there is good adoption of the Aurelia framework (which there is), you can count on a rich ecosystem and community surrounding Aurelia to allow you to find help when you need it, just like with Angular 2.

Aurelia vs. Angular 2: Takeaway

There are a number of other differences including more extensibility in Aurelia than Angular 2, syntactical differences in your markup, and how open and accurate the teams have been on keeping the community informed on coming releases. But none of these should be of much consequence to most companies or individuals trying to choose between the frameworks. Both frameworks have excellent performance and, while they may vary some on different benchmarks, neither is clearly superior to the other from a performance perspective.

At the end of the day, you can’t go wrong with either framework. To decide, start by considering the differences outlined here and try to figure out which one makes the most sense for you. You can download the sample application here. This will allow you to see a  comparison of implementing the same basic use case with both frameworks, so you can get a better feel for their approach to defining views, data binding markup, and component declarations, among other things.

Hopefully this has helped you understand the main differences between Angular 2 and Aurelia, and can help you decide which route you want to pursue.

Learn more about Angular 2 and with these courses:
Angular 2: Getting Started (if you have no SPA framework experience)
Angular 2: First Look (if you do have experience)

And for Aurelia, be sure to check out my Pluralsight course: Aurelia Fundamentals

Contributor

Brian Noyes

is CTO of Solliance, a Microsoft Regional Director, Microsoft MVP, and Pluralsight Author. Brian specializes in rich client technologies including XAML and HTML 5, as well as the services that back them with ASP.NET Web API and WCF. Brian has a number of courses in the Pluralsight library and has authored books including Developer’s Guide to Microsoft Prism 4, Data Binding with Windows Forms 2.0, and Smart Client Deployment with ClickOnce. Brian speaks at conferences worldwide including Microsoft TechEd, VSLive!, DevIntersections and others. Brian got started programming as a hobby while flying F-14 Tomcats in the U.S. Navy, later turning his passion for software development into his current career. You can contact Brian through his blog at briannoyes.net or on Twitter @briannoyes.