Ask anything to Aurelia Team (AMA)

Held on 1 February 2016, 7:00 pm

Aurelia is just JavaScript. However, it's not yesterday's JavaScript, but the JavaScript of tomorrow. By using modern tooling we've been able to write Aurelia from the ground up in ECMAScript 2016. This means we have native modules, classes, decorators and more at our disposal...and you have them too.

Not only is Aurelia written in modern and future JavaScript, but it also takes a modern approach to architecture. In the past, frameworks have been monolithic beasts. Not Aurelia though. It's built as a series of collaborating libraries. Taken together, they form a powerful and robust framework for building Single Page Apps (SPAs). However, Aurelia's libraries can often be used individually, in traditional web sites or even on the server-side through technologies like NodeJS.

Shoot us any questions you want us to answer!

Hosted by:

Having built frameworks and engineered solutions across a variety of front-end platforms for over 10 years, the Aurelia Core Team has joined together to inject our combined experience into the Aurelia Framework, a tool we know will not only help you solve the real problems in your application development, but make you happy while you do it.

Shankar K's photo

Do you believe Angular 2.0 is deviating from standards ? Does Aurelia aim to be standards compliant and independent?

Rob Eisenberg's photo

In this case, it's not a matter of belief, but of fact. If you look at the HTML specification and you look at Angular 2, you will see that they are not harmonious.

Over a year ago the Angular 2 team introduced their symbolic binding syntax. While that was technically standards compliant HTML, it was pointed out by the community that it was not compliant SVG (I have not confirmed that myself). Although members of the community pointed this out, the Angular 2 team made no changes to their design. As of Beta 2, they've actually adopted additional attribute/element syntax which involves case-sensitivity constraints. HTML is not case sensitive and thus this breaks with the specification. As a result, it is actually not possible to get Angular 2 to work natively with the browser's parser, the DOMParser API or even innerHTML because those mechanism "normalize" casing in different ways depending on the browser and thus casing can't be "trusted". This means that, if Angular 2 depends on casing (ie ngFor and ngModel attrs) then the browser won't be able to natively handle that. To solve this problem, it is my understanding that the Angular 2 team had to implement their own proprietary markup parser. Bottom line: I'm not sure what they are calling their view language, but it isn't HTML.

For Aurelia, standards compliance is very, very important. We've worked hard to align with current and emerging standards and to not do anything that would conflict with them or violate them. We have to add additional capabilities, which are not covered yet (such as data-binding) but we've done it in a way that is compliant with existing and emerging Web Standards. We plan to continue in that fashion indefinitely because we want Aurelia developers to be good Web developers.

Lars's photo

I come from angular, why should I use aurelia and not angular 2? My advantage is that I already know angular and that there is huge community. Thanks.

Rob Eisenberg's photo

First, I think it's important to correct the assumption here. The assumption is that Angular 2 is just an incremental or evolutionary change in Angular 1. That is not true. The only thing that is the same between Angular 1 and Angular 2 are the letters A, N, G U, L, A and R. They are two completely different frameworks, written in different programming languages, with different architectures, different concepts, different development methodologies, different capabilities, different communities...different everything.

I'm on my soap box here...but I think it was a bit deceptive to call this framework Angular anything. It's a completely new and different library with no ties to the old. It should have been give a new name. However, they gave it the same name for exactly the reasons you mention. They want you to not think about adopting Angular 2 because you believe it's just an incremental or evolutionary change, not something completely different.

Porting from Angular 1 to Angular 2 is massive work, even with their "migration" tools, which aren't migration tools at all. They are integration strategies. Migration actually takes a lot of work. You have to completely re-write and re-think how to write your application. Some Angular 1 application will not be achievable in Angular 2 because of they way that Angular 2 has locked down or removed certain capabilities related to dynamic composition of UI and observation of binding expressions.

Interestingly, it's actually easier to port an Angular 1 application to Aurelia. We have a ton of people in the community who have done that and have been very happy with the experience. Here's a short list of advantages that Aurelia has over Angular 2:

  • Aurelia is a much smaller library. Angular 2 is 750k minified and that does not include a router, animation or http client. That's not something anyone should ever think of going to production with ever. Aurela is 350k minified and that does include a router, animation and an http client. If you are targeting modern browsers and don't need all the polyfills we provide, you can even reduce that size by up to another 100k.
  • In the independent dbmonster re-paint rendering benchmark, Aurelia is as fast or faster than Angular 2. With our upcoming ui-virtualization plugin, it's almost 2x as fast as Angular 2.
  • Aurelia is standards compliant; Angular 2 is not. See the other AMA answer for details.
  • Aurelia better supports separated presentation patterns such as MVVM. MVC and MVP. In Aurelia, there is a clean separation between views and view-models; all responsibilities are in their proper place. In Angular 2, you have to configure your view-model with internal implementation details of the view, thus breaking encapsulation and making it difficult or impossible to re-use view-models or views. It also greatly increases maintenance cost and makes it harder for teams of developers to work in parallel on components.
  • Aurelia is very unobtrusive. For the most part you write plain ES 2016 or TypeScript code. You don't see the framework very much or at all in your JavaScript code. It stays out of the way. This is extremely important for the longevity and maintenance of your code, as well as learnability and readability. Angular 2, in contrast, must be imported everywhere and its metadata is required throughout your code. It's very configuration heavy, just as much as Angular 1, only the configuration looks different.
  • Aurelia is more interoperable with other libraries than Angular 2 because we don't use a digest or abstract the DOM unnuecessarily. The closer a framework stays to standards and the more out of the way it stays, the more interoperable it will be.
  • Finally, Aurelia is backed by Durandal Inc. The sole purpose of the company is to build Aurelia, its ecosystem and to support it. On the other hand, Angular 2 is one of six competing UI frameworks inside of Google. Each one desires to make themselves look like the "Google blessed stack" but none of them are. In reality, Google official does not back or support any of these libraries. They are open source side-projects of the various teams that build them. In the case of Angular 2, it's built by the Green Tea team, whose real job is to build an internal CRM-type application.

There are many other reasons...but that's a quick few.

Prashant Abhishek's photo

Does Aurelia provide out-of-box support for building Isomorphic/Universal apps? What is Aurelia team's opinion on isomorphic apps in general?

Rob Eisenberg's photo

Some of Aurelia is designed to run on the server, such as our Dependency Injection library, Event Aggregator, etc. These are components that are useful even in standard server-side code.

Currently, Aurelia doesn't do server-sider rendering. However, we have put in place a platfrom abstraction layer (PAL) in the current version so that no Aurelia library accesses the DOM or browser global variables directly. This is part of a plan we are working on for this year. The plan for this year has several stages:

  1. Implement the PAL (Done)
  2. Implement pre-compilation of views during application bundling (In Progress)
  3. Implement server-render for SEO optimization
  4. Implement client-side "continue" of server-rendered applications

We expect to see this plan realized in 2016.

With that said, I know that "Isomorphic/Universal" is a buzz word right now. But most developers have never tried it and don't realize how challenging it is to accomplish, even with a framework that supports it fully. Ultimately, going down that path forces you not to use any 3rd party components. You must build evertying from scratch...and must do it in a framework-specific way. This creates a lot of extra work, more expensive maintenance and web silos/vendor lockin. We will support it for developers in our community who want to go that route. But, long term, I hope that the industry moves away from this by adopting new standards such as Web Components and others that are designed to greatly improve client-side rendering.

Preetish Panda's photo

I'm interested in learning about your experiences while writing Aurelia in ES6. What were some of the major limitations/issues and what could have been done to solve that?

Rob Eisenberg's photo

I love writing in ES6! From a language perspective, there were very few challenges. All the challenges lie in the surrounding ecosystem:

  • Transpilers - Since ES6 isn't supported in browsers (in full) yet, developers need to use a transpiler. The best tools are Babel and TypeScript. We had numerous issues with Babel in the early days, just trying to deal with configuration changes and bugs. Those were managable. However, when they released 6.0, that created a big challenge for us. It's some months later now and we are still trying to get everything to work with Babel 6. We are getting close, but it's a significant amount of work.
  • Module Loaders - Modern ES6 is written as modules. When you write code in this way, you then need a module loader or bundler. This creates complexities for developers who want to use the code and creates a set of dependencies that framework authors have to rely upon in order to build, bundle and release apps. This has been very painful. It's been so painful that we are planning to build our own solution sometime later this year to help make this easier. We want to build on standards and leverage existing developer workflows, so hopefully we can make this better in the future.
Chang Hu's photo

I recently tried React but was frustrated by the setup part so how easy it is for beginners to get started with Aurelia?

Rob Eisenberg's photo

With all modern frameworks, unfortunately, setup is very hard. This has bothered me from day one. Recently, we've tried to ease this in Aurelia by splitting out two separate scenarios:

  • I want to give Aurelia a try and learn a few things before building my app.
  • I'm ready to build my app and want a production quality setup.

We wanted to make the beginner/learner scenarios very easy. So, we created some "beginner kits". One for ES 2016 and one for TypeScript. All you have to do is download one, unzip it and point a web browser at the index.html page. No installation or setup is required. This is the kit that is used during our "Getting Started" guide.

The second scenario is covered in a guide on "A Production Quality Setup". This kit involves installing NodeJS, gulp, jspm, etc but comes with a very powerful pre-configured project template that handles compiling, bundling, unit testing, e2e testing, linting, etc. Once you have the tools above installed, you can just run the application and begin adding your own code.

We're actively looking for ways to improve all of this. Your feedback is always welcome.

Cecil Phillip's photo

What can you tell us about Aurelia Interface? Roadmap? Pricing tiers?

Rob Eisenberg's photo

Progress on Aurelia Interface is going very well. I'm really excited about it. It will contain a basic set of components for forms, buttons, lists, cards, etc. It will also contain higher level UX pieces, such as navbars, tab bars and screen transitions...all fully integrated with today's router. So, it looks and feels exactly like the rest of Aurelia but gives you a way to make beautiful apps that target both Google Material Design and iOS. The entire library is themable as well with almost no work. You can also build your own themable and platform-adapting components on top of the library.

The Aurelia Interface library will be offered as part of several subscription packages. I can't give the final pricing details, but I can loosely tell you that it will be less than $100/year/developer. That would include all updates to the library for that year and it would also include some other features in the package that come along with that (which we aren't ready to announce just yet). I can also tell you that we are planning an Aurelia Virtual Conference for this year. The plan is to give the one year subscription away to everyone who attends that virtual conference.

Iñaki Pérez de Albéniz's photo

Is there any major web site built with aurelia?

Rob Eisenberg's photo

First, I like to think of Aurelia as more about web applications then web sites. If it were me, I wouldn't build my marketing home page with Aurelia. You could, but I'm not sure it's the best technology fit.

There are plenty of apps in development and production with Aurelia. As is the case with most apps, they are behind closed doors or pay walls. There are several things in development now that are "big" sites you would recognize and we have a number of "big" or "enterprise" customers. Unfortunately, we can't announce that without the customer's permission. It will probably be a bit longer before we can start talking about them.

Update: Does our docs count as a major site? We dogfood all our own stuff. Our docs app is a non-trivial application we've put in production to prove out various aspects of the framework and tooling.

Chris Cook's photo

Aurelia is a MV* framework. What do you guys think about uni-directional data flow ( Flux, redux etc.)?

Rob Eisenberg's photo

Building a system using uni-directional data flow is a great goal. It's a desirable characteristic and one that Aurelia supports through it's one-way data-bindings. We also support this through strict component encapsulation. However, it's important to realize that not all systems can be built this way in their entirety. In meetings, both the Angular 2 and React teams have admitted that complex applications will almost always contain cycles, and that uni-directional data flow is not possible in those scenarios.

In summary, I think it's a design principle that should be strived for but that you should realize that there are reasons to break the rules. Part of being a good developer or architect is understanding where and when that needs to happen.

With respect to Flux, I would just want everyone to realize that there are various ways to achieve uni-directional data flow. Sometimes, something like Flux is an over-complication. You can achieve something similar by following a standard Repository+Event Aggregator pattern (drawing from Fowler's PoEAA and Evan's DDD ideas).

Stephen's photo

I have used Aurelia and love it.

But my management voices worries that Aurelia might be "some guy writing code in his garage" (and hence is not a long term framework to bet on).

I know you have many volunteers helping make it great, but how many paid developers do you have working on Aurelia?

Rob Eisenberg's photo

I think this question has a fundamentally incorrect assumption. The idea is that only products and companies built by salaried employees can succeed. However, almost every major tech company today is evidence against that fact: Facebook, Microsoft, Apple, Google...and on and on. Some of these literally did start out as guys in their joke.

On the other side of things, we have countless examples of products built by salaried employees that were shut down by their companies. For example, there are fulltime paid members of the Angular team...and yet Angular 1 is planned for obsolescence despite that it is still the most popular framework today. Why? Because Angular 1 doesn't align with the internal goals of the Green Team team that creates it. Another example from recent news is Facebook's shutdown of Parse. Those were full-time paid employees working on that. Yet, it was shutdown. My guess didn't align with the business goals of Facebook.

The key to success is the symbiotic relationship between a company and its customers. The customers have a problem and the company solves it. That helps the customer's business to survive. Then the company needs to address the continuing needs of the customer to enable the company to survive. It's about partnering together. This is the best way for open source to work too. When the company has no dependency on the customers...can it really meet the customer's need? Does it have a business reason to even try? I think the obvious answer is no.

If you are wondering about corporate structure. Durandal Inc. is a Delaware C Corporation. Currently, there are 10 million shares of common stock. There are three founders: a CEO (me), a CDO (Scott) and our Services Architect (Patrick) Equity, payment and benefits are provided in various degrees to our three founders and members of our core team, listed on the Aurelia web site's team page. We are globally distributed and work in much the same way as Wordpress, from a business perspective. We also have a network of official consulting and training partners. Durandal Inc. has a business plan, both for the long term and the short term. We are about solving real problems and partnering with companies to help their businesses succeed. That's something that almost no other framework can offer.

Jimmy Javier's photo

I'm learning EmberJS, and I like it, so my question is: what would be the reason I could switch to Aurelia instead of a framework like the one I mentioned before?. By the way, I worked with Durandal and I enjoyed using it with KnockoutJS. Greetings

Rob Eisenberg's photo

Well, if you worked with Durandal before and enjoyed using it, you will LOVE Aurela. It's basically a next generation version of Durandal. However, I think Ember is a good choice. It's not the way I want to build apps, but I think it's a reasonable choice. The only frameworks I recommend to people are Aurelia and Ember. Everything else either has technical issues, standards issues, business issues, etc. If you like Ember, by all means, use it. We'd rather you use Aurelia, for obvious reasons though...

Tom M's photo

Novice here.. How does Aurelia stack up against Angular and React? In other words, why should one use Aurelia to build apps instead of something like React?

Thanks in advance.

Rob Eisenberg's photo

I'v answered some of this with respect to Angular above. So, have a read through there for more information on that. Some of the same points apply to React. I'll re-iterate them here from that perspective:

  • React is a smaller library than Aurelia, so they've got us beat on size. But, that's not entirely accurate because React is only a view engine and in most cases developers end up adding lots of 3rd party libraries together to create their homegrown framework. In this case, it's possible to end up with infrastructure code that is larger than Aurelia. Also, the developer has to maintain the sometimes tenuous connections between the libraries they have chosen. Aurelia gives you a complete platfrom, out of the box, so you don't need to worry about that as much.
  • In the independent dbmonster re-paint rendering benchmark, Aurelia is about twice as fast as React. With our upcoming ui-virtualization plugin, it's almost 4x as fast as React.
  • Aurelia is standards compliant; React is not. Basically, you have to adopt jsx which is neither standards compliant JS nor does it use standards compliant HTML (it has different properties and casing rules).
  • Aurelia supports separated presentation patterns such as MVVM, MVC and MVP. React provides only the view layer, so you must implement these yourself. Typically, I've found that React developers don't do a good job of this and wind up not following separated presentation patterns at all.
  • Aurelia is very unobtrusive. React is utterly intrusive. It uses a different language and infects the code of every component and screen.
  • Aurelia is more interoperable with other libraries than React because we don't abstract the DOM unnecessarily. The closer a framework stays to standards and the more out of the way it stays, the more interoperable it will be. Usually, React developers have to rebuild just about everything. It's difficult to use jQuery or 3rd party widgets not specifically designed for React. This creates silos within the web which isn't good. Frameworks should be designed to interoperate.
  • Finally, Aurelia is backed by Durandal Inc. The sole purpose of the company is to build Aurelia, its ecosystem and to support it. On the other hand, when asking a React team developer about Fracebook's committement to React they said "Facebook isn't committed to React. We are committed to some of its ideas, but not to the library." It's an open source project within FB that has no connection to their business model. It's replaceable like anything else and it's probably not up to the developers who work on it if and when that will happen.
Daniel Greene's photo

I can see that Aurelia supports Web Components. I would like to know Rob's opinion on web components in general and how Aurelia utilises this technology.

Rob Eisenberg's photo

We believe in supporting web standards. We want to take advantage as much as we can. Currently, all views in Aurelia are created using Web Components HTMLTemplateElement. Also, any component in Aurelia can opt into using the Shadow DOM. We provide a fallback when your browser doesn't support it...and we provide support for the same programming model even when you don't want "true" Shadow DOM. Aurelia custom elements don't use the Custom Element spec directly, because in the context of a framework, there are almost no advantages to that...and some disadvantages. However, we have a plugin, releasing soon, that will enable any Aurelia element to be exported as a custom element. We've actually built this so that our Aurelia Interface library can be used without Aurelia...just as plain Web Components. We think this will be meaningful for other component authors as well. In this way, using these components inside an Aurelia application will get the Aurelia-optimized behavior, but they can still be used as spec compliant Web Components in any other context, including inside other frameworks.

Another way of looking at Web Componnents is not just in terms of what technology do we use, but how do we integrate? Aurelia was designed from the beginning so that Web Components from 3rd parties could be used directly inside an Aurelia application. The binding and templating systems were designed to work correctly in those scenarios. Today, we have a number of developers building Aurelia applications, but using Polymer Web Components as their widgets.

Dong Nguyen's photo

Nice to see you here. Is there any way to compile/babelize the whole source code of Aurelia core and its extensions and all modules by developers into just one file from server?

Ashley Grant's photo

In our Skeleton Navigation project, we provide sample configuration to create a bundle that includes all of the necessary Aurelia Framework components (

This code utilizes our Aurelia Bundler which works with JSPM's bundling functionality to create an Aurelia bundle for your app.

Rob Eisenberg's photo

Yes. We have a tool called aurelia-bundler. You can use that to create any number of bundles you want from your source code. Our docs app, for example, is deployed as two bundles. One that contains aurelia and all 3rd party libraries and one that contains the application-specific code. You can read the docs on bundling here:

We are constantly working on improving bundling. We have lots more features planned for the future.

Raymond Wood's photo

Thanks for doing this Q&A session.

My question is : What was the initial motivation behind creating Aurelia?

Rob Eisenberg's photo

When I was hired to work on the Angular 2 team, I was told one thing about the project, but as time progressed I realized what I was told and what I was asked to do did not align with what was happening internally. I realized that Angular 2 was not something I wanted to use, not something my community wanted to use, and probably wasn't something that much of the Angular 1 community would want to use (if they knew everyting I knew). So, I left the Angular 2 team to build a next generation platform based on adherance to web standards, designed to solve the real problems that developers face in the real world. I found out that much of the Angular team had little to no experience building apps even with their own framework and just didn't understand the challenges faced by developers. I had 10 years of consulting experience in the front-end and front-end frameworks and felt I could help people address their issues based on that experience.

Bottom line is that there are real problems and challenges that the Angular team was not addressing but that I Aurelia could.

Dan Lourenco's photo

I've been following Aurelia for almost a year, and have been really impressed with the progress made since it was first announced. What's the best way for your average web developer to help out the Aurelia community? Are there needs in terms of tutorials? Documentation? Evangelization? I want to do my part to make sure web developers know that Angular and React aren't the only major players out there.

Rob Eisenberg's photo

This is my favorite question so far! Thanks for your willingness to get involved. Yes, everything you mentioned is appreciated. We would love for you to help us get the word out there. Blog, speak at user groups and conferences, tweet, etc. If you write a cool post on Aurelia or build a neat sample app, let us know and we'll tweet or blog. Help with the docs is always appreciated. We have an open issue on the documentation repo that is tracking the articles we want to write. If you see something there that interests you, let us know and we'll help you to write it. Every author gets credit in the docs, so it's great for you personally as well.

Of course, submitting issues, and helping us fix bugs is always good. But, it need not be anything that technical, if you aren't comfortable. The things you've listed above are a huge way to help us and the community.

Charles Zamoresen's photo

Does Aurelia have support for building native mobile apps like react-native?

Rob Eisenberg's photo

Primarily, Aurelia is about the open web platform. We aren't into promoting platform or vendor lockin. I've been burnt by that many times in the past. The world we want to see is one where native apps no longer exist and all apps are built with open web technology. To that end, we are building a capable platfrom and ecosystem to obviate native.

That said, as mentioned in other questions, Aurelia is built on a platfrom abstraction layer (PAL) and is a combination of carefully decoupled components and services. It's quite possible that an enterprising community member could make it work with native. But ultimately, I'm not sure that abstracting away the native platform is a great idea. I've seen that go badly many times over. Keep in mind that things like react-native aren't new at all.

Raja Sekar's photo

There are multiple frameworks already there and coming in. So why Aurelia?

Rob Eisenberg's photo

You will see some answers to this throughout the other answers here in the AMA, specifically comparing only a few features to Angular 2 and React. A brief summary could be like this:

  • Aurelia is a medium size framework, smaller than many others and with no external dependencies.
  • Aurelia is as fast or faster than all other frameworks.
  • Aurelia is more standards compliant than most other frameworks. (Only Polymer is at the same level.)
  • Aurelia is the most unobstrusive framework today. There is nothing that even comes close to comparing.
  • Aurelia integrates very well with other libraries. Other frameworks like Angular and React have a harder time with this.
  • Aurelia has the best support for separated presentation patterns (MVC, MVVM, MVP) of any modern framework.
  • Aurelia is better at dynamic, data-driven UI construction than anything else today.
  • It is the only framework written in 100% ES 2015/2016 with no dependencies except polyfills. (At least that we are aware of.)
  • Aurelia has no unnecessary DOM abstractions. So, it can be faster than and consume less memory than other frameworks.
  • Aurelia has some of the best support for Web Components. (2nd to Polymer but when our new webcomponents plugin is released in a few weeks, we will be on equal ground with them.)
  • Aurelia is the only framework built with a modern, modular architecture.
  • I could go on and on.

Here's a couple of links:

Joshua David's photo

I like the frameworks with the philosophy of "convention over configuration". What is Aurelia's philosophy?

Rob Eisenberg's photo

Aurelia is all about "convention over configuration". We work really hard to let you write plain, vanilla JavaScript code, follow a few naming conventions...and then it all just works. We are strong believers that frameworks should stay out of your way and make the most common tasks easy. Take a look at our getting started guide. I'm sure you will find it very compelling.

Norma King's photo

How can Aurelia guarantee that it won't see the same fate as Can developers really trust Aurelia?

Jeremy Danyow's photo

Facebook acquired Parse back in 2013. It's an enormous company and Parse was just a very tiny part. If it's this easy for Facebook to change direction slightly and drop an official, paid-for, supported product like Parse, imagine how easy it is to drop an unofficial, unsupported, free open source project like React.

Contrast this with Aurelia which is essential for the overall success of Durandal Inc.

You might find the discussion here interesting: Variety of developer perspectives

Full disclosure: I'm on the core team, so obviously biased. I do not work for durandal inc nor do I receive any $$$ from durandal inc

Koh Wang's photo

I just found out that Aurelia team members are working remotely. That's really commendable. How is that working out for you? Any experience worth sharing?

Rob Eisenberg's photo

Working remotely brings it's benefits and challenges. I've been working as a consultant, most remotely, for about 12 years. So, this type of development is familiar to me. The ecosystem and tools are also really coming into their own space now. We do a lot with the community through Github and Gitter. We use Zenhub to add Kanban style boards onto Github. We use for video meetings. All of this technology is very affordable and helps these types of workflows. As always, there are things we can do better. We're learning from this process and adapting as we grow. I'd love this to continue as the standard way our team works. I think it's liberating to be able to tell our developers they can go wherever they want and work whenever they want, as long as we work together to build awesome stuff :)

James B's photo

Can we use React.js as view with Aurelia? Would you recommend that?

Rob Eisenberg's photo

We have some developers using React with Aurelia. I haven't done it myself, but it's being done in the community. If you do that, I'd be curious to know why. The developers who went that route earlier on did so for performance, but Aurelia's latest releases are much, much faster.

Ultimately, though, it's up to you. We built Aurelia to be very interoperable. So, it works today very well if you want.

Claudio Mezzasalma's photo

Hope you don't mind for a second (and a third, while I'm here :P) question :)

Being so popular, one of the big plus of Angular is the great availability of documentations in various forms -- among that, books. What about Aurelia? Is there any project for a (or more then one) book? It seems I didn't find anything, even from publishers which usually supports "Beta" ebooks publishing (i.e. partial releases of a reduced set of chapters).

Also, it seems Angular 2 supports RxJS for functional programming; it's even included in their official quickstart application. What about Aurelia? By reading other replies it shouldn't be that hard to plug it in; am I wrong?

Rob Eisenberg's photo

I've got good news for you.

There are three major publishers working on Aurelia books already. There is also currently a Pluralsight course on Aurelia and two more planned for release in the next month or two. We are also getting contacted by other video sites who are interested in providing content on Aurelia. Oh...and we've got our own stuff planned too. So, there's content and much more on the way.

As far as RxJS goes, you can use it today with our async plugin. This plugin drops into the binding system and enables it to bind directly to Promises and Observables. We've also designed our BindingEngine API, Event Aggregator and other services to return Observable-like objects so that they are future compatible with APIs that work with observables.

Lino's photo

First of all - congrat guys! Gitter is great, but it's bad if you need to search to find something that maybe someone else already asked... So, is there any chance that you open some kind of thread based forum?

Rob Eisenberg's photo

Yes. Absolutely. We plan a full thread-based forum, integrated directly into our docs and other areas of the site. We're even going to build the front-end in Aurelia (with an off the shelf backend).

Eddie Lee's photo

What's the story for knockout.js with aurelia? Will there be an official way to plug in knockout views when migrating old code bases to enable a smooth transition for durandal apps?

Rob Eisenberg's photo

Aurelia's data-binding engine is adaptive and can be taught how to observe different types of objects. We've actually got a prototype adapter that enables Knockout observables to work seamlessly with Aurelia. Core team member, Jeremy Danyow, can provide further information on that.

Robert's photo

Just following this AMA has given many great reasons to try Aurelia. Whats a good starting point to learn it?

Rob Eisenberg's photo

I would highly recommend that you start with our "Getting Started" guide. You can find that here:

There is also a Pluralsight course by Scott Allen. There are two more Pluralsight courses coming in the next month or two. Three books coming as well.

We're constantly working on our docs. It's a big part of what we're doing in the beta period. If you have trouble getting started or can't find the answers you need, we would invite you to join our gitter chat:

Also, if you aren't apposed, you can sign up for our mailing list. We aren't evil...promise. I hate junk email. We will use it for major announcements only.

Sandeep Panda's photo

What were the major challenges that you faced while getting everything to work with Babel 6?

Rob Eisenberg's photo

Well, we haven't got it all to work with Babel 6 yet ;) But, here's the two big things that have made this process slow:

  • Decorators - Aurelia and it's developers make use of the ES 2016 proprosal for Decorators. When Babel 6 was released, they dropped support for this. That was a deal killer for us. Now, there is a plugin based on the same spec as Babel 5. That solves one of our problems.
  • Plugins and Ecosystem - There are lots of things around Babel that need to be updated to work with the new version. For example, the pluggin Babel into Karma. Also, we had a plugin for generating TypeScript d.ts files from Babel. That needed a complete re-write. So, it's the forced upgrade of the entire ecosystem that has taken time. Those things are falling into place we expect to be able to move everything to Babel 6 soon.
Cyril's photo

How can I convince my CTO or a colleague to use Aurelia? What is your marketing plan to become more and more famous and attractive? Thanks!

Ashley Grant's photo

I've been working with a dev who created a POC to show how much easier it is to develop applications using Aurelia than with competing frameworks. It was turned in to a competition with internal teams creating the same POC in the different frameworks. They then came together and discussed the pros and cons they found while working with the frameworks. Aurelia ended up winning the competition.

As far as making myself more famous and attractive. Well, I'm going around speaking about Aurelia.

Making myself more attractive is a lost cause though :-/

Michael Malone's photo

During the development of Aurelia there have been some fairly show-stopping bugs at most release cycles - will you be adopting a more conservative development strategy after release and do you have/what are your concrete plans to improve the testing strategies?

Jeremy Danyow's photo

During the alpha we added hundreds of unit and integration tests. More are being added all the time. In the shift to beta we've really narrowed the scope of the changes we're making. When there were breaking changes they were fixed very quickly, often within hours. We'll continue to work on improving our release process during the beta and beyond.

The main strategy is (and always has been) to write tests for any changes that are made. Some aspects of the framework are harder to test (mostly the templating and routing related features) so it's taken longer to get coverage in these areas.

Beyond improving the test suites, there's work going on setup code coverage and automated cross-browser tests in all the modules.

Cas du Plessis's photo

I'm in the process of a building my first aurelia app, which I initially built in Polymer. Although I found the aurelia learning curve a bit steeper, I'm now well on my way. We are already using react.js in our organisation. So, my question is specifically around aurelia vs react performance. Have you guys done any benchmarking against competing frameworks/libraries?

Jeremy Danyow's photo

We've done a ton of benchmarking and plan to do more. We have a benchmarking app that exercises various aspects of the binding, templating and dependency-injection modules. This app is used to validate changes we make improve (or at least don't degrade) performance. There are several posts on the official blog related to performance, here's a couple links:

We're looking at performance from a variety of angles, render speed, memory consumption and cross-browser testing are all important aspects of this work. Recently we uncovered an issue with Edge's promise implementation that was slowing down our initial render in that browser:

In terms of Aurelia vs React, in our testing, it turns out that NG2 is the closest framework to us in terms of all around perf. React is much slower in non-trivial scenarios like dbmonster.

Grey Davis's photo

How difficult/easy is it to port my existing Angular application to Aurelia?

Shuhel Ahmed's photo

As Rob mentioned in another post, it is surprisingly easier to port Angular 1 to Aurelia than Angular 1 to Angular 2. You almost can keep your view/templates as is with Angular's binding syntax. Aurelia can understand that too. Watch this video where Rob explains it.

Isaac's photo

Andre Staltz, creator of cycle.js says React and Redux is inferior paradigm, do you also think so? Do you think his points are valid?

Rob Eisenberg's photo

My knowledge of cycles.js is limited to the one video presentation I watched from Andre. So, I probably can't give a real definitive answer here. I can tell you that I found his argument compelling and that his component creation strategy seemed much more consistent with functional programming than React is. My understanding is that, performance-wise, it is slower than React, which could be an issue...or maybe not. I don't know from practice.

Personally, I would just use Aurelia...but that's obvious :)

Lino's photo

I know it doesn't affect us (users of Aurelia framework), but internally what are the main reasons why you have chosen Babel vs TypeScript? From today's perspective (Babel 6 problems) - do you think it was a wise decision? Today - switch to TypeScript is not an option?

Rob Eisenberg's photo

We wanted to stay as close to the standards as possible. Babel was and is still the best tool for that. Switching to TypeScript would take some effort because TypeScript would put additional constraints on our codebase and some of the ecosystem is still not as mature as Babel. I witnessed the Angular 2 team move from Traceur to TypeScript...and the many months that process took them when they thought at first it would only take a few weeks.

We are constantly evaluating this though. What was the best choice when we started may not always be the best choice. We have a good relationship with the TypeScript team and it may be that in the future it makes more business sense for us to move to TS. I don't know just yet, but the arguments for that do get better as time passes.

We do make efforts to have good TS support and I think it's a great choice for building applications.

Fonz's photo

Been following Aurelia with interest since I first heard of it. Some questions already about putting strong case in front of management. Currently working on proof of concept app using Angular and some D3.js charts. Any Aurelia based examples with charts etc.?

Rob Eisenberg's photo

Yes. I'm not sure if I've got a public link for D3, but I do know that people from the community have used D3 with Aurelia. There are a bunch of Telerik Kendo UI chart demos here though:

Jason Hughes's photo

Why Aurelia when there's already Durandal? Couldn't you've built a new version of Durandal with ECMA 6?

Shuhel Ahmed's photo

Aurelia is Durandal with ES6 and beyond. Initially it was Durandal 2.0 and later renamed to Aurelia. You will find many similar conventions and configurations. For instance here is the route configuration:

export class App {
    configureRouter(config, router) {
        config.title = 'Aurelia';[

             { route: ['', 'welcome'], name: 'welcome',      moduleId: 'welcome',      nav: true, title: 'Welcome' },

             { route: 'users',         name: 'users',        moduleId: 'users',        nav: true, title: 'Github Users' },

             { route: 'child-router',  name: 'child-router', moduleId: 'child-router', nav: true, title: 'Child Router' }


    this.router = router;

This should be familiar to you as a DurandalJS developer. Only difference I see is this is written in ES6 utilizing the clsss syntax instead of an AMD module .

We have the same convention for view/viewmodel pair. You can do everything that Durandal offers in Aurelia plus more.

Jeremy Danyow's photo

It would not be accurate to call Aurelia "Durandal 2". It's a complete rewrite.

Durandal brought together knockout (for data-binding), requirejs (for module loading) and Q for (promises) to produce a full featured SPA framework.

When building a standards-based version (Aurelia), you don't need knockout, requirejs or Q.

eikaramba's photo

You already compared Aurelia with Polymer in the past, however can you elaborate in how far it might make sense (or not) to combine these two? e.g. polymer has a great UI library, that was actually our reason to use it (i know about AI :) )

Rob Eisenberg's photo

Basically, you don't want to combine the two in the sense that you write your own components and application code with both. But you could combine the two in the sense that you write your application with Aurelia and then use Polymer elements inside your Aurelia views. Since Polymer's best feature is its component library, it makes a lot of sense to combine them in that way. In fact, community members have been doing that for a while and we even have a plugin and documentation for that use case. You can read more here:

Andrianarivony Leon's photo

By reading questions and answers, i would like to give our experiences since the beginning of Aurelia. Personnally, i'm coming from .Net platform and wpf. So starting to develop a SPA is like a challenge for me, so choosing the right framework is not easy because we need to take into account some criterias. Sometimes, it's good to give some criticism, ReactJs nor Angular are not really suitable. It's really hard to accept to write a lot of code or writing HTML in a Javascript code, to achieve simple things. Coming from WPF, Aurelia looks like natural, coding, conventions and syntax for 2016 year:-). Not only these, the entire Aurelia Architecture Design is what we should expect today: Extensibilities and Standard; it's futur Proof. We built production web sites today and we are happy. Sure, it's still missing some pieces like SEO, Server-Side Rendering, Package Loader, Local Storage Caching,... But we know that many new things are coming .... My 2 cents,

Rob Eisenberg's photo

Thank you Leon. See today's blog post about aurelia-cache in development :) You can also load packages today with the proper bundle configuration. Please see our bundling docs for some examples. The other features are planned for this year :)

Claudio Mezzasalma's photo

Hello. I'm constantly following Aurelia development and its journey. I noticed that some issues with jspm in particular happened recently. Can you provide some more details about it, and how will this influence future development?

Rob Eisenberg's photo

JSPM is making some major breaking changes in their 0.17.x release. We have attempted to update Aurelia's package.json files so that Aurelia could be installed with either 0.16.x or 0.17.x. We spoke with Guy from the JSPM team extensively about this so that we could do it right. However, there were a number of things Guy didn't expect and things didn't go as smoothly as we wanted. As of now, we do support 0.16.x with some restrictions which we've outlined in today's blog post. We are working with Guy to finish the last changes needed to support 0.17.

This isn't the first time this has happened to us. So, I confess, I'm not very happy with the situation. We will continue to support jspm/system.js, but post v1 we are also going to be investigating our own solution. We'd like to support as many package managers, loaders and bundlers as possible. However, our recent experience has led me at least to believe that we may be able to build something much simpler and more stable ourselves which could become the default in the future (without cutting out anything we already support today.)

Cyril's photo

When will you reveal your "Project X"? Is Aurelia Interface part of it?

Rob Eisenberg's photo

We really need to update that. I forgot it said that :) Project X really refers to several things we are working on. Aurelia Interface is the first of those that we will release. We are also working on a set of components more-geared towards Line of Business applications. There are other things we're planning to that we aren't quite ready to announce yet.

Stephen's photo

I have noticed that the JQuery input plugins that I have tried to use with Aurelia breaks Aurelia's "value.bind" (ie: jquery.maskedinput, jquery.autotab). (By "breaks" I mean that the bound JavaScript value does not get updated.)

Is this something should (or eventually will) work?

Or do most JQuery input plugins interfere with he DOM too much to be able to do a value.bind?

Jeremy Danyow's photo

It's almost always some variation of a very simple issue:

When a JQuery plugin changes the input element's value programmatically, the DOM doesn't fire any "change" or "input" events, so Aurelia never "sees" the change.

The fix is to hook into the plugin's update callback and fire the DOM event manually. Here's a classic example using the JQuery UI datepicker:

Stephan's photo

Will aurelia-validation dependencies continue to get updated, or will we end up with forks? It would be a nightmare for us, if our app have to include different aurelia versions. We don't want our bundle size to grow even larger.

Rob Eisenberg's photo

We are doing some major re-work to aurelia-validation. Once that is finished, we'll be able to make it part of our normal release cycle. Additionally, as we move to jspm 0.17.x we will be able to use peerDependencies which will solve a number of these issues. So, no forks needed. We don't want that.

Shuhel Ahmed's photo

I am sure it will. We see no reason not to. It's an official Aurelia package and we are committed to keep it healthy and well now and in future.

Cecil Phillip's photo

It seems that observables will be a part of ES7. Any thoughts on how Aurelia might leverage them in future features ?

Jeremy Danyow's photo

At the very least we'll be able to handle observables in the binding system with a plugin. Here's one that supports binding to the eventual value of Promises and Observables:

If adding capabilities via an optional plugin somehow limits our ability to integrate with observables we could look at adding support directly, but I doubt that will be necessary. In my experience Aurelia and ES7 Observables are compliment each other nicely.

Cecil Phillip's photo

Some time ago I recall there were some issues with Babel when v6 was released. Can we reliably use the newer versions of Babel with Aurelua today ?

Ashley Grant's photo

We're getting close. It's been a lot of work for the team to deal with the issues that arrived with Babel 6.

Carlos Saloio's photo

What is the recommended way to observe array mutations? Observatory.getArrayObserver, BindingEngine.collectionObserver, other?

Jeremy Danyow's photo

Use the BindingEngine's collectionObserver method. Check out this answer on stackoverflow for more details:

Simon Ruis's photo

Just out of curiosity - Is the commercial version of Aurelia available yet? What are the extra features?


Rob Eisenberg's photo

There isn't a commercial version of Aurelia. However, you can purchase commercial support or enterprise support for the open source Aurelia, if you want or need it. We can discuss your company's needs and put something together for you. If you are interested, just email support at durandal dot io

We are planning some commercial addons such as Aurelia Interface and Aurelia Business components. You can read up on them on our official blog: There's some discussion of those here as well in other answers.