Every generation has its war.

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.

I have nothing but praise for both Ember and Angular. Both give you real data binding, and delegation rather than events. Compared to Backbone, both are like being in heaven rather than the 4th level of "event" hell.

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

:(

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

I am mostly a systems dev but I have written my share of websites. They are all built with just jQuery. Can someone englighten me the need for data bindings and all these frameworks?

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)

I get that this was written in quick response to the earlier post about AngularJS, but it would have been far more useful if it had actually drawn direct comparisons between the two frameworks.

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.

Note that if you have, say, HTTPS Everywhere installed, the embedded JSFiddles won't display. The site the post is hosted on supports HTTPS, while JSFiddle apparently does not, so Firefox blocks "loading mixed active content".

I just used ember to build a side project (http://bests.com) and it turned me into a huge fan. It is great how little code you need in ember to tie an API with a UI in the browser.

Your answer to "why it rocks" is "data binding." Why does this seem like an important feature to you? What problem does it solve?

Everybody is trying to emulate the old (VB, Delphi, etc) way.

You can see the important difference between Amber and AngularJS in the 'computed properties' snippet of Amber:

    App = Ember.Application.create();

    App.ApplicationController = Ember.Controller.extend({
        name: '',
        greeting: function() {
            if (this.name.length < 1) return '';
            return 'Hello, ' + this.name;
        }.property('name')
    });

You write this to use a property 'greeting' in a view that's calculated from a different property 'name'. This works for one model, but imagine you have dependencies across different model objects, nested properties, and so forth. Seems like it'll get complicated pretty quickly.

In AngularJS, that's just (in the template, or a controller function, or where ever):

    {{name + greeting}}

AngularJS uses dirty checking, which makes it trivial to implement complicated interdependencies between various fields. Any plain JavaScript code will work, including model objects that were not written as Ember code.

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.

  {{name}} {{greeting}}

  {{name + greeting}}

    {{#if name}}Hello, {{name}}{{/if}}

I see ember and angular on hn today...are the backbone evangelists on summer vacation?

I still can't let go of knockout, because it gave me such a hard time to learn it. I think what is needed are migration guides or services for various frameworks to Angular, the de-facto standard.

I don't really like to mess with front-end stuff. Can someone explain why ember/angular are so amazing? What does it enable you to do so much more easily?

I say once you do our own or add databinding to backbone, life is very very good. I love the events on the models views and collections. I was almost thinking about writing a databinding where it only updates one property at a time on change. Why update the whole view or model. Is that provided in any backbone addition?

Well, seeing everyone saying how good ember is, here is a counter-argument:

http://discuss.emberjs.com/t/getting-started-with-ember-js-i...

We shouldn't compare backbone with EmberJS or Angular. Backbone alone is not MVC framework. I started with Backbone worked with Marionette but Ember is so awesome that now i even use for simple pages.

The example given for the "components" argument in this article is very contrived and unpersuasive.

Have a look at http://ractivejs.org

Ok but what am I going to use this data-binding for? Ensuring that nobody will ever have to (GASP) click a "calculate" button? I mean what am I supposed to use this for?

The site does not work for me.

I don't care.

The fact that this isn't "it doesn't" in full capitals and 72-pt font baffles me

I think it's important to remember that Backbone is not one library but a modular ecosystem. I am a huge fan of Backbone Marionette + Relational + ModelBinder as a very valid alternative to Ember and Angular.

Even comparing Backbone (by itself) to these two is futile. It's thin, doesn't prescribe much, and doesn't even promise to offer what Emb/Ang do, so to compare them is unfair to all involved IMHO.

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

You sound like you know your way around both frameworks.

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.

Once a project gets big I switch to the Publisher/Subscriber pattern through a main Mediator rather than using the default Model/Collection change events.

That is to say that I cannot relate to your 4th/any hell level.

* not useful in github (simple page with some js extras on top, it's a prime job for jquery)

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

While this isn't really the place to explain it. What takes you 20 minutes with observer listener pattern takes less than 1 in angular (can't speak for ember). It is life changing if you've always hand rolled your own JS.

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

jQuery is great for progressive enhancement. Github serves mostly static pages, and then some javascript that adds a bit of functionality on top.

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

Each time I'm looking at the code of my previous web apps which are built with jQuery, I think how many boilerplate code here, could be replaced by Angular-code in 3-4 times less amount of lines and without many bugs (copy-paste is their reason and it's my sin, but because of often repeated boilerplate code). But it's not enough reason to rewrite them :)

Along with maintainability, which others have mentioned, I would throw out there that Angular is generally easier to test than your average jQuery scramble.