Angular 1.x Concepts In Aurelia


If you’re like me, you’ve worked with Angular a lot or you are currently working with Angular and over time you have grown accustomed to its very concepts; controllers, directives, factories, providers and services. In Aurelia those concepts can exist, but not in the way you think.

If you’re thinking of porting over an Angular 1.x application to Aurelia, below we will touch upon various concepts to make the transition as easy and seamless as possible.

There will not be any code comparison, this article assumes you have opted to choose Aurelia for your next or current application and you come from an Angular background, wanting to understand new concepts.


One of the things I really hated about Angular is the confusing directive syntax. A directive can be both an attribute or element. In Aurelia they’re not called directives, we have two separate types we can choose: Custom Attributesor Custom Elements.


In Angular we have all of these confusing ways of creating singletons; providers, factories, services and resources. In Aurelia a ViewModel/class is presumed to be singleton by default. We even have the option of declaring it as transient as well. Read more hereabout Aurelia’s dependency injection.


Nope. There are no controllers in Aurelia. All you have is a ViewModel that is rendered either by the router or some other part of your application. Aurelia is not an MVC framework.


In Aurelia the concept of filters does exist, except they’re more aptly named value converters. As you can see herethe syntax is almost the same. Porting over Angular filters to Aurelia should be a breeze.

Binding & Templating

If you’re porting an Angular application, this part will be the most important. Understanding how Aurelia deals with displaying and binding to values in a view opposed to Angular.


Keeping inline with ECMAScript 2015 templating, all Aurelia HTML template views require <template></template>tags to properly acknowledge themselves as views.

Expressions & Strings

In Angular we used double curly braces to display values and perform expressions inside of our HTML. Because Aurelia utilises ECMAScript 2015/2016 specifications, we can use string interpolation instead.

In most cases simply retraining your brain to use ${}instead of {{}}is all you need to remember when working with Aurelia. You can read more about string interpolation viathe official Australia documentation.


In Angular we have; ngClass, ngHide, ngInclude, ngRepeat, ngSrc and so on. In Aurelia there are counterparts to these features found in Angular.

ngClass– class="${myClassString}" ngClick– click.trigger="function()"or click.delegate="function()" ngHide– show.bind="" ngInclude– <require from=""></require> ngRepeat– repeat.for="item of items" ngSrc– src.bind="" Databinding

In Angular we had the likes of ngModel, ngValue and other bindings for working with form input values. In Aurelia we still have this concept, the API however is easy to understand use.

One Way Binding

By default .bindwill assume a “one-way” binding relationship for all attributes, with exception of form element values which use “two-way” binding by default.

In Angular to achieve one-way binding, we need to use something like ngValueto prevent a two way relationship or ngChange

One Time Binding

A one-time binding means that a value is not bound at all, there is no observation happening. The value is just printed into the page as is and any future changes will not update the value.

In Angular we have the confusing {{::myVar}}and in Aurelia we have a more verbose""

Two Way Binding

All form elements in Aurelia are presumed to be “two-way” bindings. Any non form elements are presumed to be “one-way” bindings by default. However, given Aurelia offers a verbose way of binding, we can simply use: value.two-way=""and we have two way binding.


As you can see Aurelia simplifies your workflow. From working with databinding, to templating and custom expressions. The lack of abstraction means you spend less time scratching your head and more time coding.

If something did not make sense or I missed an important aspect of Angular that should have its equivalent covered in Aurelia, leave a comment below or drop me an email.