Rob Eisenberg on Aurelia and how it stacks up against Angular 2 and React

Last week Rob Eisenberg and Aurelia Team went live on Hashnode to answer questions about Aurelia Framework. It was a nice Q&A session with lots of interesting questions. Here is a summary of the session (You can check out the full Q&A session here).

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

Rob : 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.

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. — Lars

Rob : 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.

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

Rob : 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 theamable as well with almost no work. You can also build your own theamable 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.

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. — Tom

Rob : I’ve 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 platform, 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 Facebook’s commitment 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.

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

Rob : 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 platform 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 everything 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 lock in. 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.