Why does Ember.js rock?

[brianwillis]

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.

[zanny]

> friends and coworkers who are too young to remember the atrocities of old

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.

[jmspring]

Funny how so much of todays "wars" center around Javascript at the front end or bringing it down into lower levels/the back end -- nodes, etc. I like to refer to it as the era of the "Webscale Wars"...in homage to the awesome Mongo/Node webscale/rockstar bad ass tech videos.

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.

[6cxs2hd6]

> I fear this generation's war will soon be upon us.

At IO 2013 I saw someone leaving the Angular session.

I did a double-take.

His name badge: Kyle Reese.

[dustingetz]

Yes, thank you. There are a lot of very loud, authorative and dismissive opinions from people who clearly don't understand all the other ideas in this space.

[jcampbell1]

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

[djacobs]

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.

[padolsey]

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

[cheapsteak]

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.

[agilebyte]

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.

[gunn]

:(

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

[Kerrick]

Quick fix here until I find a fiddle equivalent that allows SSL embeds: https://kerricklong.com/articles/why-ember-js-rocks.noembed....

Sorry about that.

[general_failure]

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)

[nolok]

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

[Volpe]

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

[perlgeek]

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

[EugeneOZ]

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

[hackula1]

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

[gklitt]

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.

[glitchdout]

There was a link posted in the other discussion (by visionscaper) that makes the direct comparisons that you suggested. Personally, that's also what I want to see in these types of blog posts.

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.

[mintplant]

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

[azakai]

I get that on Firefox Nightly with no extensions installed.

[rickharrison]

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.

[moocowduckquack]

"I just used ember to build a side project (http://bests.com) and it turned me into a huge fan."

Did it also send you spinning? (sorry)

[progx]

I look at your code and i think for this small project you can use jquery and ajax. Where does it use the advantages of a big framework like Ember?

[tantalor]

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

[rogerthis]

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

[10098]

I was just thinking about this yesterday. Remember how easy it was to build a working UI in Delphi? Throw some controls on the form with a few clicks, maybe write some code, and it just worked. By comparison, integrating various javascript widgets into existing applications still remains such a pain, you'd think we've receded into the stone age of application development.

[Nitramp]

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.

[manmal]

I'm not sure I really catch your drift, but:

Using

  {{name}} {{greeting}}

in Ember should have the same effect as

  {{name + greeting}}

in your example, right?

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?

[Kerrick]

I wrote that contrived example to show off computed properties. In idiomatic Ember.js, I would have written the template as follows, with no Computed Property (indeed, no explicit Controller) needed:

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

[capkutay]

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

[mayhew]

Backbone is a library, not a full-fledged framework like Ember and Angular. I could see Ember and Angular being implemented with Backbone. Backbone isn't opinionated and makes no design decisions for you. It's also very low-level (no two-way binding).

Not really fair to compare them, they cover very different use cases.

[Kerrick]

Ember and Angular are new now. Backbone was new two years ago. I'm guessing that's why.

[julianpye]

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.

[yakz]

I don't think you see much about Knockout around here because it comes from the ASP.NET MVC world. It's a nice lib, regardless. I would not describe it as being similar to Angular or Ember at all, though.

[sanarothe]

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?

[bdcravens]

Take a jumble of jQuery that is continually updating the DOM via event callbacks and function calls and giving you structured code that wires it up in a smart way. In the same way you don't need a framework like Django or Rails, but server-side code tends to turn into a mess without one.

[halis]

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?

[kumarharsh]

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

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

[renekooi]

That link says nothing about how good or bad Ember is, it refers to a lack of Getting Started documentation.

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/

[itsbits]

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.

[kenster07]

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

[ekanna]

Have a look at http://ractivejs.org

[overgard]

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?

[ollysb]

I'm using it to display analytics. The page has various controls to view different metrics with different filters etc. there's a single chart which updates as you change settings. The backend is super fast so the chart updates almost immediately when you change metrics/filters. Our users absolutely love it, it's so much easier for them to learn the interface when the feedback loop is so quick.

[Volpe]

Have your objects update from a form fields without having to select each element, assign it's inputted value to your JS object.

Turns 50 lines (if you're lucky) of JS into 0. (with about 10 characters more markup).