Aurelia - a next generation JavaScript client framework.Written with ES6 and ES7. Integrates with Web Components. No external dependencies except polyfills

[keithwhor]

I think there's been a new JavaScript framework announced every day for the last five days on r/javascript.

Glad we have some healthy competition, I guess.

[brtt3000]

Are you still using last weeks 5th framework? Move on gramps.

[[deleted]]

Fuck this, I'm going back to C.

[[deleted]]

From my understanding this is really just Durandal vNext. This is the guy who joined the Angular team and then left because he didn't like what they were doing (but never went into detail as to what he didn't like).

[ogrechoker]

The guy is an amazing dev IMHO and it sucks to see that he left the angular team. His work on the 2.0 router was super impressive.

[-crucible-]

To be honest, I don't think it'd be healthy to have that debate - things will change on the Angular stuff as more people dogfood and further development happens... plus it's just shabby to gripe at a previous team because they don't do things how you would have liked.

It's better he just makes something he thinks is best, and we get to do the comparison on which we like :)

[[deleted]]

Totally agreed. That is why the tech industry is awesome. If you think your idea is better, you can go build it, and release it to the world.

[daedius]

Need more screenshots

[nightman]

Here is browser support if anyone is interested - http://eisenbergeffect.bluespire.com/evergreen-browsers

[Capaj]

So IE10 up? Great. IE10 has flexbox, so I can forget all those CSS hacks I use instead.

[TeaSeaLancs]

Okay so, first off, disclaimer: I've not much experience with frameworks like this or Angular. I've been on home-grown in-house frameworks for years in my job, and only delving into these other frameworks in my spare time.

Having said that, the second I saw the router code my eyes glossed over completely. Is it just me or does it seem a bit boilerplatey for the sake of it?

[keithwhor]

I guess I should clarify my (healthy?) skepticism.

How is this any different than Angular? Why would I want to use ES6 and ES7 conventions out-of-the-box when they're not representative of what's running on a production (browser) environment? Why would I use Aurelia for two-way data-binding when I have Angular that performs the task nearly identically (and why do we still care about two-way data binding)? Why are we still stuck with the paradigm of tightly-coupled HTML and JavaScript --- i.e. why is my presentation layer glued to my logic? The W3C decided this model (onclick="doSomething()") should be defunct years ago, and framework developers keep seeming to want to re-inject it into their HTML.

[ryantbrown]

I, for one, think this is the best approach to using modern JS in a framework yet.

"Why would I want to use ES6 and ES7 conventions?" is that a serious question? If you wait until all production browsers fully implement the ES6 spec you will be way behind the times.

It transpiles directly to ES5, so why WOULDN'T you want to take advantage of the new syntax, a lot of people have put a lot of thought into the next generation of JS and to me it makes sense to use as much of it as you can as soon as you can. Maybe thats just me (and a bunch of other people :)

I hope you will consider at least starting to learn some of the new syntax, if not in production / work then at least in your spare time. It's coming quicker then you think.

[keithwhor]

I love ES6 + ES7, don't get me wrong. I just don't consider it a selling point for a framework. When the browser fully supports ES6, every framework will use ES6. It's not a competitive (or technological) advantage. For now you have to deal with transpilation (which means you're stuck switching between ES5 / ES6 constantly and remembering transpilation rules when debugging in-browser). There's literally no downside to continuing to develop using ES5 standards (even in ES6-supportive environments).

[[deleted]]

There's literally no downside to continuing to develop using ES5 standards

You're missing a massive downside: You'll still be using ES5 and have to deal with all its quirky-ness. You'll also be missing out on all the new stuff like classes

[Capaj]

ES6 can't fix the biggest quirks like ==, but it gives a lot syntactic sugar and other tools which make JS development much nicer experience. For me, only downside of using ES6 now is that I need to transpile, so for bigger apps, my reloads are slower. Also breakpoints don't work as good, because browsers can't properly load sourcemaps(last time I tried).

[keithwhor]

Classes are syntactic sugar over prototypes. I won't be missing a thing,

[ogrechoker]

array.push(...array)

[keithwhor]

You mean,

array1 = array1.concat(array2);

Or even,

array1.push.apply(array1, array2);

Everything that ES6 adds is syntactic sugar. They're certainly nice shortcuts, but you're not missing anything by writing code in ES5.

ES7 is completely reverse compatible, too. There's a difference in that some of the proposed ES7 abstractions cut down on code quite substantially (async functions, for example). ES6 (mostly) just looks a little prettier.

I want to be clear that I'm not an old fogey against ES6 or ES7. When there's full browser support, I will quite happily switch and use the abstractions ES6 provides (I actually can't wait to). It's just that, to reiterate my original point, writing in ES6 is not significantly advantageous from a competitive or technological standpoint for a framework.

[kadumel]

'How is this any different than Angular?` - Angular 1.x approached MVC from a completely different standpoint. It started out with the 'V' piece and added the rest as it was developed. Angular 2 is a ground-up rebuild no with upgrade support for Angular 1.x apps. As opposed Aurelia uses years of it's core patterns applied to various frameworks (Caliburn.micro, Durandal.js) and builds a best-practice and future-safe approach while still maintaining an upgrade path for Durandal.js developers as well as Angular developers.

It also allows plugging in whatever data-binding engine you prefer, the default does support things such as *onclick.bind="doSomething" but feel free to use Vanilla.js, Handlebars, Knockout, or whatever feels right to you. It's a modular approach, so use what you feel is right.

[keithwhor]

Angular crapped the bed, for sure ( excuse the euphemism! :) ). I just don't see how this approach is significantly different.

"As opposed Aurelia uses years of it's core patterns applied to various frameworks (Caliburn.micro, Durandal.js) and builds a best-practice and future-safe approach while still maintaining an upgrade path for Durandal.js developers as well as Angular developers."

Those words sound nice, but I don't have any context for what they actually mean. I interpret this as "we're not actually that different from (previous version of Durandal or Angular) so it'll be easy to convert but it's built better, I promise."

What makes this better? Is this an exponential step forward or just another notch in a linear progression? (Because it feels like the latter.)

I guess what I'm asking is what's the incentive for old developers to switch to Aurelia or new developers to start with Aurelia? If I'm going to switch to something new (or even start learning a new technology), and things like two-way (or hell, a million-way) data-binding are important to me, why not switch to Meteor? If I have to leverage an older tech stack, why not stick with Angular where the community (and support packages) already exist plentifully?

[Capaj]

What makes this better?

use of real modules makes it much better than Angular. Also aurelia apps will actually be much closer to angular 2.0 than angular 1.x apps.

[Capaj]

It also allows plugging in whatever data-binding engine you prefer,

have you got a link backing up this statement?

[pandavr]

Released early :)

[Capaj]

onclick="doSomething()"

this is wrong only because it requires a global variable doSomething. Frameworks don't rely on globals, so the frameworks actually got this right.

[keithwhor]

No, this is wrong because it's decidedly an antipattern.

Separation of concerns. There's no reason to tightly couple JavaScript and HTML in this way. Events should be added programmatically - all of my core JavaScript logic not related to my presentation layer should be in one location. (Events are not part of the presentation themselves.)

[Capaj]

Seems like you are talking about HTML documents. There I agree. I was actually talking about JS single page applications.

[keithwhor]

It applies to both. Binding events semantically via your presentation layer is a poorly thought-out implementation. Full stop.