This is the new version of a framework that has been around since 2012. I have no milk in my fridge from 2012.
1. Large focus on ES6/ES7
3. MVVM as made popular by libraries like KnockoutJS (which Durandal was built upon).
I think this is awesome. While I don't plan on rewriting an app I'm already working on in it, I think the interface to the framework is very very simple (which is refreshing), due in large part to the tight ES6 integration.
Also, I think MVVM is preferable to MVC (mostly because "controllers" are an overloaded term and end up being VMs anyway), but that's just a personal opinion (as is everything else I wrote).
But all the frameworks, the view syntax/binding gubbins is horrid. Hard to debug, easy to make syntax errors. Bleugh :(
On an app I'm currently developing, I've actually adopted the pattern of using knockout with some other libraries (directory, for routing, mainly) and actually have found relative success.
One thing I have been tossing around in my head though is creating a web development pattern (I'm really just avoiding using the word "framework" here) that does this by default (and intentionally).
My vision for it is to be a marrying of knockout (for data-binding & templating & components), director.js (for routing, I think pager.js, while well intentioned, is too complex), and requireJS for async loading, with everything but knockout being optional.
I'm thinking of calling it chainmail (because the power is in the combination/linking together of the small libraries) -- would you be interested in something like that?
Also, have you checked out the components feature of knockout lately? it's awesome
I found the docs really hard to follow, and they seemed really complicated (and I didn't think it should have been)... It is entirely possible (and even likely) that I didn't put in much effort. But knockout (and tools like it) hit such a sweet spot for me because they are (almost) dead-simple.
That being said, I'd really be interested in something like you've described.
Right now I see the MV* web framework landscape (from lightest to heaviest) as:
I'm aiming for chainmail to fit inbetween knockout and mithril (I consider it less than mithril because it will not include a JS-based dom structure, and will be using templating from knockout.
Small confusion: They chose to use 6to5 and jspm but jspm depends on Traceur and there is even an issue for supporting 6to5 on jspm issue tracker. (Edit: Just discovered that they were answering questions on Gitter)
There are no calls to document.registerElement() in the framework or templating repositories, and it looks like any element registration is happening against a proprietary registry, so that Aurelia components won't be available in standard web pages outside of the Aurelia framework, which would be the exact same situation we already have with Ember, Angular, React, etc.
Can someone from the Aurelia team clarify this?
Web Components are not yet a standard. They are primarily being pushed by Google without taking much feedback from other vendors. I spent almost a year working with building frameworks around them...and decided there was no real advantage to using document.registerElement for an Application Framework.
Again, if you want to build Web Components or use Polymer...that is fine. You can use that with Aurelia. But Aurelia's custom elements aren't built that way.
As a side note, Aurelia will be able to "export" its custom elements to Web Components. So, before we hit v1 you will be able to do that and then take an Aurelia Web Component into a non-Aurelia app and use it, the same way you would use a Polymer element. We haven't done that yet because we are focused on the application experience first and foremost.
So, we use 3/4 of the spec. One of the APIs we don't use...but we will allow you to export your Aurelia elements to a document.register form for v1.
I get the impression we're dealing with a framework that is based in part on Durandal, so it is not an entirely new framework in certain aspects (I could be wrong). And on the plus side, Rob has proven himself as an effective leader on projects like this and during his time on the Angular 2.0 team, he was doing some great work.
I assume that he's currently the CTO of a very small company (of maybe even just him), and one of the ways to do that profitably, while building things you love, is to consult/provide training on the things that you have built that others want to use
Pain points I found with the Knockout based app: Performance, stupidly messy data flows, hard to test, lack of isomorphism. My choice of React/Flux for my next project was based on that: React makes a big deal about performance (virtual DOM), sensible data flow (flux architecture, one-way data flows, events, etc.), testability, and isomorphism.
I clicked on OPs link with some apprehension; is the stack I just chose already outdated? Not according to the blog post. They still need a "bunch of work" on performance and testing (which implies that it's not there yet, and also raises questions about priorities; testing seems like it should be more than an afterthought). There's no mention of isomorphism. And while technical details are sparse, it looks like there's no virtual DOM; no strongly enforced event model (like React has with Flux). Maybe it's there, but...
...given the amount of experience the author has writing JS frameworks, I'd have expected a lot more details on how this framework solves problems the programmer might have with other frameworks. I mean, the very first bullet is "Aurelia is written with vanilla ES6 and ES7 but transpiled and polyfilled to work on today’s Evergreen browsers. It may just be the most forward-thinking framework you've ever seen", but speaking just for myself, I've never ever thought to myself "man, this framework is awesome, but if only it had been written in ES7 and transpiled to work in my current browser!" I'm struggling to imagine why anyone would think that.
Now, maybe it's just a bad blog post. I'll do some more digging. But the message I'm getting so far is "this framework was created to solve the kind of issues framework authors care about, not the issues developers using the framework care about". If true, it's not a good message.
In short: Get off my lawn. :(
"Use some of the libraries on the server with NodeJS. i.e. DI." - some, and I'd expect an explicit mentioning of isomorphism if it were possible at the moment to render it on the server side.
Shadow DOM != Virtual DOM. I mean the React-style Virtual DOM.
Or do you mean the hint that some of the code can run server-side? That seems obvious, and is not in itself isomorphism.
If a platform claims to support isomorphism, I expect it to render server-side with zero drama/workarounds/blog posts. Support means that producing fully-rendered html is a core part of the product and documentation, not something glued on the side or pieces to reassemble on your own.
From the wording, it looks like Aurelia isn't there yet?
"I am not saying that Angular 2.0 is going to be a bad framework. What I am saying is that it is no longer fundamentally the same thing I was originally hired to help build nor is it compatible with my vision for the future. It is no longer the best path ahead for the existing Durandal community and it also isn't the best choice for anyone who has used my other frameworks and wishes to migrate to the web."
This is what people are talking about in countless blog posts (that also make their way to the front page of HN.)
So glad I'm not a front end dev trying to keep up with this world.
On the other hand, rapid evolution leads to better ideas, keeps your mind fresh as your learning never ceases, and an opportunity to improve yourself, keep your career in demand, and generate more income for yourself.
Example: when I started web dev, client-side code was basically a giant function containing browser-specific DOM manipulation.
Today, client-side code is arranged in modules with single responsibility, well-defined application architecture, easy to test, easy to modify or extend, the app logic cleanly separated from the UI.
Rapid evolution also keeps the mind fresh. You're continually learning new concepts, absorbing new ideas. This helps me enjoy my job; I'm always learning.
Rapid evolution keeps my skills in demand, too. My last 2 gigs have been because I learned Angular. I'd be hard-pressed to find work if I was still building web apps like it was 1998.
If a framework learns from the mistakes of the past and builds on previous success, then I welcome it.
Anyone got a link on how to test an Aurelia app?
By combining ES6 modules with a simple, yet powerful Dependency Injection Container, we make it easy for you to create highly cohesive, yet minimally coupled code, making unit testing a snap.
What version of phantom are you referring to? Do you have any specific examples?
Compared to what? Selenium? I hope you're not comparing to the testing included with angular, because those are two different kinds of tests. Also, in the end, I think the most important kind of test is the kind of test you write with something like phantom/selenium because it requires that the system (at a macro level) does what it's supposed to do. If you make a todo app, you can have all your unit tests pass and the app still be broken. You definitely can't have your integration/end-to-end test pass if the app doesn't actually work (though the functions may be terrible, buggy, etc.
Personally (I have no data to back this), but I doubt Angular has seen remarkable adoption because of easy testing.
[EDIT] - I just noticed that you ignored the mention of Jasmine -- Maybe Angular shouldn't require it's own testing strategy at all, that seems like a pretty good indicator of a monolith (which Angular is, so I guess that's not really an interesting point).
I've also had to work around weird JS issues that only affect Phantom, and corrupted screenshots making it rather hard to see what's going wrong. For our team's time-spent vs time-saved, Phantom has been a waste. Our app is very JS-heavy, but that's why I thought Phantom would be a good idea.
I think the most important kind of test is the kind that developers will actually use. If tests are hard to understand, hard to run, unreliable, or slow, then they won't get used (Selenium!).
I just want idiomatic, quick, easy-to-write tests so regressions in our app are much less likely to happen. Angular's approach met those requirements pretty well and that was a big influence to our choice to use it (two years ago, data point of one). It looks like React has a good approach to testing too.
If the Aurelia docs suggest using Jasmine to test the application, especially if they help setting up html fixtures and data, then that's encouraging. But I don't think they do. For now it's all DIY so, if I join your Aurelia team, I have to spend a bunch of time learning how your testing works? In my experience, that means your project will most likely have very little testing.
Also agree with writing tests that devs will actually run, though I think that is going away with the advancements in orchestration/devops. If buildbot or jenkins can run the tests then you may not have to rely on a human's willingness to run it. Speed's another matter though.
Oh and no, they don't suggest using Jasmine to set up the application (not that I read) -- that was just my assumption (that you could). And that's a very good point, if they don't pay attention to testing (and make it very obvious/easy), then it will fall by the wayside.
It doesn't really cover testing the application, right? Or, is the implication that app writers should do the same thing?
Error 1008 Ray ID: 1af3b92032e50713 • 2015-01-27 08:54:00 UTC
The owner of this website (blog.durandal.io) has banned your IP address
Me: What tools/framework did you use to build the app?
Me: Oh cool, I used Thomas.
You: Yeah, I thought about using Thomas, but stuck with Aurelia because it offered better features.
And my brother is named Lisp, so it gets weird. :).
(i've always wondered if their not recognising "miranda" as a language was a miss or a subtle joke on illiad's part)
"The easiest way to learn and experiment with Julia is by starting an interactive session".