Get the Newsletter

Aurelia Mid-October 2015 Releases: Performance and Portable JavaScript

Posted by AureliaEffect on October 13, 2015

Wow. Wow. Wow. We are getting really close to our beta release! Today's releases bring you some major overhauls to performance, memory consumption, internal design consistency and platform portability. Read on to get the details.

New Features

  • PAL - This release introduces a Platform Abstraction Layer (PAL) which enables Aurelia to remove all dependencies on browser globals and specific runtime environment capabilities. Different implementations of the PAL can be plugged in to enable Aurelia's libraries to run in the different environments available today. This is a fundamental enabler for view pre-compilation, browser-less testing and server-side rendering for SEO and isomorphic scenarios.
  • New DI and Binding Engine Internals - The usage of DI and data-binding is the same as it's been for months, however, we've re-vamped the internals of these libraries in order to reduce memory pressure and improve performance. This releases contains some great improvements in these areas. We'll have a follow-up blog post to talk more about the performance work soon.
  • New bindingEngine facade object enables easy use of various databinding APIs.
  • New templatingEngine facade enables easy use of various templating APIs.


  • The module loader abstraction has been significantly cleaned up and improved to shield developers from any future changes in the module loader specification.
  • The new bindingEngine and EventAggregator follow the same pattern of returning subscription objects for event management.

Breaking Changes

This looks like a lot of breaking changes, however most of these related to internal structures and shouldn't affect you much if at all.

  • If you were using the AggregateError type, it is no longer in the logging library. It has been moved to the pal library. However, like before, it is also exported by the framework library.
  • The levels enum in the logging library has been renamed to logLevel for consistency.
  • The metadata library's exports Decorators and Metadata have been renamed to decorators and metadata respectively. Since these were object exports, not classes, we wanted to be consistent with standard JavaScript casing practice and lowercase their names.
  • The DI library's Container has an instance method named hasHandler(). This method is being deprecated and will be removed for the beta release. It has been replaced with hasResolver().
  • The EventAggregator now returns a subscription object from its subscribe method. The subscription has a dispose method to unsubscribe from the original event.
  • BehaviorInstance has been renamed to Controller, to better reflect the templating engine's internal MVC architecture.
  • The BehaviorInstance/Controller's bindingContext property has been renamed to model to better reflect the templating engine's internal MVC architecture.
  • The primaryBehavior property that used to be on custom HTML elements has been removed. Instead, there is a new au property. The object that is returned from accessing this property has one property for each Aurelia API associated with the element. There will be a controller property pointing to the Controller instance of the custom element. Each of the other properties point to Controller instances for each/any custom attributes found on the element.
  • The templating engine's test helper APIs have been moved to the templatingEngine object. If you are using Aurelia APIs in a unit test, you will want to jspm install aurelia-pal-browser --dev and then import the initialize method from that library, invoking it in any test file. This will ensure that you have the browser implementation of the PAL present for your tests. If you wish to mock out aspects of the templating or binding engines, then you can call templatingEngine.initialize(container) providing a pre-configured container instance for it to use. You can create instances of your custom element or attribute models with for testing with let instance = templateEngine.createModelForUnitTest(ModelType, optionalHTMLAttributeKeyValuePairs, optionalBindingContext);
  • The view resource pipeline's analyze callback has been renamed to initialize.


  • Dependency Injection - As mentioned above, the entire internal implementation of the DI library has been re-written in order to improve performance and reduce memory pressure. The new implementation is also more consistent internally and more flexible. Various parts of Aurelia are taking advantage of the new design flexibility.
  • Databinding - As mentioned above, the internals of the binding engine have had a massive overhaul. The changes include a dramatic reduction of object/array/closure allocation, resulting in improved performance and lower memory consumption.
  • The repeat attribute now has the ability to re-use views. The developer can set the view cache size on a per template basis with view-cache="number|*" on any template.
  • Some additional performance work was done in the templating engine.


  • The html-template-element polyfill library is deprecated. The updated polyfill is now included in our pal-browser library as part of the core browser platform.
  • The global-behavior is being removed in the next release. This was an experiment to see whether we could automatically generate jQuery behaviors on the fly. In retrospect, we don't think it was a good idea. If you like it, it can easily be added to your own project.
  • The with custom attribute is being removed in the next release, most likely. We would like to have this long term, but currently there are some issues with it and we need to remove it until we fix a couple things inside that binding engine that would enable building this in a better way. Again, if it works for you, it's just a custom attribute, so you can add it to your own project.


This is the last release we'll have before beta. We are planning Aurelia's Beta 1 to launch in about 2-3 weeks. The Beta 1 release will also include our new documentation.

We also plan to do a Beta 2. The primary reason for this is that the Web Components specs have recently changed. We don't think we can address the spec changes in the Beta 1 timeframe and we don't want to "spring" it on our community for the final release. So, we're going to do a second beta release to address that. We'll also be able to make some other improvements as part of that as well. Once the Beta 2 is out, we're going to let the libraries "simmer" for a bit, while we fix issues and continue performance improvements. After a period of time (to be determined based on community feedback) we'll make the v1.0 release.