Ask anything to Aurelia Team (AMA)

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.

Ask a Question

93 discussions

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

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.

Reply to this…

Hashnode is a friendly and inclusive dev community.
Come jump on the bandwagon!

  • 💬 Ask programming questions without being judged

  • 🧠 Stay in the loop and grow your knowledge

  • 🍕 More than 500K developers share programming wisdom here

  • ❤️ Support the growing dev community!

Create my profile

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.

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.

Reply to this…

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?

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.

Reply to this…

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

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.

Reply to this…

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

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.

Reply to this…

Load more responses