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

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.

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

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

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

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

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.

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

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

I would highly recommend that you start with our "Getting Started" guide. You can find that here: aurelia.io/docs.html

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.

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. durandal.us10.list-manage1.com/subscribe

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.

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

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.

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';
        config.map([

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

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.

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.

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:

danyow.net/jquery-ui-datepicker-with-aurelia

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

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.

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: github.com/jdanyow/aurelia-computed/blob/master/R…

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.

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: blog.durandal.io/2015/12/04/aurelia-repaint-perfo… blog.durandal.io/2015/12/17/more-aurelia-performa…

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-edge-…

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.

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.

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

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.

Use the BindingEngine's collectionObserver method. Check out this answer on stackoverflow for more details: stackoverflow.com/a/30286225/725866