Why does Ember.js rock?
kerricklong.com
kerricklong.com
My forefathers fought the great war of emacs and vi in the 1980s. Those were dark times, which many still refuse to speak of. When I think of the horrifying atrocities committed by both sides, the snarky BBS posts, the bickering over usenet, it shudders the mind.
My generation got off relatively lightly. There were a handful of skirmishes during the browser wars which were difficult on the civilian population. Tables being used for layout, limited CSS support, that sort of thing. While many a fine web developer met their end at the hands of Internet Explorer 6, a lot of us (some would say, the less patriotic) chose to ride out the war as desktop application developers, avoiding the draft entirely.
Today I see many of the young and impressionable being manipulated in an ardent search for desperate glory. They get roped in by blog posts, conference talks, friends and coworkers who are too young to remember the atrocities of old. I fear this generation's war will soon be upon us. It will not take place in mobile as many had expected (the Android/iOS battle was a classic case of corporate manipulation), but instead will be fought in Java Script.
Missing in a lot of this is that many of these tools that allow for "X is OMFG so amazingly awesome and webscale and ..." is years of churn, some progress towards "standards", and a foundation in lower level languages that enable these technologies.
In the gold rush, those that sold the shovels, the jeans, and the food made the bigger, less riskier dollar. In the coming generational war, as you posit, if it were to occur, having a toolset that includes things beyond Javascript will be key. In seriousness, especially on the nodejs front, any serious application you develop will run into bottle necks...in nearly 99% of those cases, just javascript isn't going to get you out of them. Breadth in experience, tooling, and mindset has it's advantages.
At IO 2013 I saw someone leaving the Angular session.
I did a double-take.
His name badge: Kyle Reese.
I'm 21. If I'm working on a project, I'll use whatever the guy paying for it wants. If I get a choice, I'll use what I'm most experienced in.
There is no magical solution at the end of the rainbow. The only real important consideration is that 99.9999% of code you will write has already been written and is probably open source somewhere. A lot of that ends up in a library. And a lot of that is still maintained to this day. So rather than look for a framework to reinvent the wheel in as quickly as possible, relearning the entire stack every time (or at least the framework, which I find takes the longest just because it constitutes huge amounts of library functionality and dictates the workflow) is almost always a waste of effort.
In my defense, I have experienced the "reinventing of the wheel" many times that didn't work or caused a lot of unneeded growing pains, starting probably with Netscape 6, but more recent examples are Gnome3, KDE4, a lot of switching between wxwidgets, gtk, qt, and efl over the years, and the duplications of work associated with them, even if I am young in the profession.
There are a lot of differences, but if I had to pick, it would depend on the application. If I was building something with complex front-end requirements where the vocabulary was mostly tabs/panes/switches/filter-dropdowns/etc., then I would go with Angular. If I were building something where the data domain was more important, e.g. the vocabulary is more about authors/titles/posts/tags/etc. then I'd go with Ember.
With Ember, persisting a complex model to a backend is a priority for the framework developers. With Angular, it is left as an exercise for the reader.
With Angular, extending the DOM to create new web components is a central focus, but with Ember, it is totally an after thought. Ember Components are a joke compared to Angular directives...
I was about to link to the Ember component source code showing how pointless they are. (A week ago they were useless) The devs have been furiously fixing Ember Components to have the power of Angular JS directives. I am so happy to see the good parts of Anular making their way into Ember. For those that hate Angular terminology, it appears 'isolate' has made its way to Ember. I hope 'transclusion' does as well. Need more than one way to {{yield}}
I'm reluctant to try something big with Angular because of its insistence on dirty checking, which just ends up being an annoyingly leaky abstraction half the time (see $timeout, for example).
I don't get your reference to $timeout - $timeout is Angular's more testable wrapper around setTimeout for an asynchronous operation. AFAICT it's entirely unrelated to dirty checking - sometimes you just want something to happen later. Am I missing something?
That is to say that I cannot relate to your 4th/any hell level.
export var mediator = _.extend({}, Backbone.Events);
m.mediator.on('change:page change:sort change:tags', this.renderTable, this);
m.mediator.trigger('change:sort', sortOrder);
this.paginator.bind('change', fn, this);
Edit: A link from Addy Osmani: http://addyosmani.com/largescalejavascript/#mediatorpattern
The messages I send are more light weight and usually say "this has happened" to which a View would respond by re-rendering itself or its part rather then me directly passing whole Models and Collections around.
Check out this talk: http://vimeo.com/68987289
How long would it take to learn both of them, if you're already familiar with Backbone?
Are there yet any comprehensive resources to learn either one, similar to Addy Osmani's Developing Backbone.js Applications book? The videos like Ember 101 and Egghead are nice, but I worry that they don't go deep enough.
[blocked] The page at https://kerricklong.com/articles/why-ember-js-rocks.html ran insecure content from http://jsfiddle.net/Kerrick/Vd6eF/embedded/result,html.
Unfortunately kerricklong.com won't serve http, nor jsfiddle.net https, so I don't see an easy fix.
Sorry about that.
For example, say, github.com. Where in that website would I use data bindings? Or say gmail for that matter. The idea of bindings is not alien to me but I just fail to appreciate why bindings are useful for most websites.
(I do understand backbone.js but I just feel I can write what I want in a observer/listener pattern in 20 mins instead of bothering to learn all intricacies of a framework)
There is not too much to either of these frameworks. A solid day and you'll be productive. There are many layers to becoming an expert, but (at least with angular) you can just use the bits you know, and refactor as you learn more.
i.e. You don't have to know anything about what "directives" are to build an app
But consider writing a spreadsheet application instead, where changing one cell can influence a lot of others. That seems like a good use case for data binding (though I admit I haven't used it so far).
* for gmail you would use it to handle emails for example. Your view in gmail never changes, if you're looking at tags, or archive, or sent mails, or inbox, ... It's always the same thing, but the dataset changes; it comes from different sources, it is sorted and filtered different, ...
For a Gmail clone with angular, you do you app/html/css one time, and then you only ever manipulate your model, everything else is done for you. Want to filter email to only get those tagged "hacker news" ? Map reduce your email set then assign it to your model, that's it - no dom no event assign no view logic no nothing, only data.
Now, I'm pretty sure you read this and you think "but I could do the same with what I'm used to, just create a setEmailList(emails) function and use it", that is entirely true. Angular does not provide new functionnalities that you couldn't get otherwise. What angular provide is that
1 - it will be way faster to code than your "traditionnal" method once you're used to it, because angular does most of it for you, and
2 - large changes, special cases and thus evolution of the app are much easier to handle and code.
It provide those two things by being made explicitely for them. Angular is so tailored for that use case that it sucks and should never be used for anything else. Don't be fooled by all the hype into thinking every website should now use angular/ember/whatever, they shouldn't. It does only one kind of job, but it does it very, very well.
I'm currently using AngularJS for a project, and loving it. Everything in this blog post looked like something with a close equivalent in Angular (data binding => data binding, components => directives, Handlebars Helpers => filters), so I didn't see any compelling reason to try Ember.
It is great to see competition in this space though! It seems that full-featured JS frameworks are progressing rapidly because of it.
Cage Match – Ember.js vs. AngularJS : http://vimeo.com/68215606
I still haven't had to pick one side, but this talk will certainly make me lean towards some framework. I just wish it was a 4-sided battle with Backbone.js and Knockout.js since those are the other 2 frameworks that are on my radar.
While Ember and Angular seem to be pretty close in terms of functionality etc, Angular has recently gained a lot of momentum judging by Google Trends, blog posts and available 3rd party libraries (http://ngmodules.org/).
This might not be important for everyone, but when I could just plugin an Angular bootstrap model and stuff worked, I was happy and chose Angular.
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-bloc...
Did it also send you spinning? (sorry)
Did somebody really looked at Ember and its Ember-Data and the missing features that you need when you program a RESTful application? E.g. Server Errors. Ember "Frontend" is nice, but Ember "Backend" is (in my mind) not production ready.
And only for a little two Way Binding 800 KB of Code? ;-) I think Ember has more to give.
It is a pity that the perception of delphi is that it is yesteryear's technology, because in my opinion it is still the absolute best way to build windows native apps, better than microsoft's own tools, and technologically they are really onto something with firemonkey on top of their data binding layer (which does two-way data binding in a more powerful way than any of the web frameworks).
See this example of building an app in delphi xe4: http://docwiki.embarcadero.com/RADStudio/XE4/en/Tutorial:_Us...
Note that i'm still doing web development though, because the era of the desktop is fading for the sort of software i'm making. I'm just aware that as good as frameworks like angular and ember are, they have a way still to go.
App = Ember.Application.create();
App.ApplicationController = Ember.Controller.extend({
name: '',
greeting: function() {
if (this.name.length < 1) return '';
return 'Hello, ' + this.name;
}.property('name')
});
In AngularJS, that's just (in the template, or a controller function, or where ever):
{{name + greeting}}
This comes at the cost of the dirty-checking loop (checking each expression in a tight loop on every user 'event'), but in my experience that's at least not a problem for normal desktop web applications.
Using
{{name}} {{greeting}}
{{name + greeting}}
You need not use computed properties in Ember, because updates on ordinary model fields are also updated in templates in real-time (AFAIK works very similar to KVO in Objective-C). Computed properties are just a ridiculously useful concept which allows you to modify/transform stuff before you show it to the user, similar to the view-model in MVVM. How would you show an empty string in Angular with "{{name + greeting}}" if name is empty?
{{#if name}}Hello, {{name}}{{/if}}Not really fair to compare them, they cover very different use cases.
http://discuss.emberjs.com/t/getting-started-with-ember-js-i...
Last time I checked (which was a few weeks to two months ago) the documentation was mostly of an 'intermediate' level, ie. hardly any documentation on the easy parts and hardly any documentation on the hard parts. It looks like it's gotten tons better since, eg. http://emberjs.com/guides/getting-started/
Turns 50 lines (if you're lucky) of JS into 0. (with about 10 characters more markup).