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.

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.

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.

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.

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.

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:

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.

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.

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.

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).

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.

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.

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

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

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 basement...no 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 here...it 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.

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.

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: aurelia.io/docs.html#/aurelia/framework/1.0..

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

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.

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.

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.

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.

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. aurelia.io/docs.html#/aurelia/framework/1.0..

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.

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.

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 zoom.us 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 :)

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.

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.

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?

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: wpdev.uservoice.com/forums/257854-microsoft..

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.

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?

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.

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 now...so we expect to be able to move everything to Babel 6 soon.

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.

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.

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: gitter.im/aurelia/dicuss.

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?

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.

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?

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:

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.?

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: aurelia-ui-toolkits.github.io/demo-kendo/#/..

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?

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.

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: blog.durandal.io. There's some discussion of those here as well in other answers.

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.

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.

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.

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?

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.

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?

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.)

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 :) )

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: aurelia.io/docs.html#/aurelia/framework/1.0..

By reading questions and answers, i would like to give our experiences since the beginning of Aurelia. Personnally, i'm coming from .Net platform asp.net 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,

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 :)