Backbone vs Ember

I absolutely agree that comparing actual apps is a very useful point of comparison.

Ember itself is actually relatively new. The fact that Ember inherited some of its runtime semantics from SproutCore might give the mistaken impression that there is shared code. Everything, including Ember's runtime, was rewritten from the ground up for Ember, and it's only with the release of Ember 0.9 that I consider the APIs and codebase stable.

Some companies, like ZenDesk, hopped onboard earlier in 2011, while the codebase and APIs were still undergoing a lot of churn, and helped flesh things out. That said, when taking the scope of Ember into consideration, Ember's adoption curve is behind's Backbone's, so it's not surprising that there are many more impressive Backbone apps in the wild.

We're proud of many of the apps that people are building with Ember today, and as the year progresses, hope to compare favorably to Backbone's impressive list.

Hey, Ember.js maintainer here--

Luckily, providing a widget library is, and will always be, outside the scope of Ember.js. While we'd be quite pleased to see someone else develop a widget library on top of Ember, it's not something that we're personally interested in doing.

The goal of Ember.js is to roll up common patterns web developers are using into the framework so that they can write less boilerplate. In fact, part of the reason we renamed SproutCore 2.0 to Ember.js was to emphasize the point that our value proposition is in the architecture, not the library of controls.

As a veteran of the SproutCore project, keeping things lean and focused is my top priority. And, if it helps, we're all extremely allergic to anything that feels "enterprisey." :P

Can't we all just get along...

I've been working with Backbone intensively since V0.1, and though I've very scarcely looked at ember, I've been following the heated discussions on both sides. Personally, I think it's damaging to both your publicizing efforts.

Perhaps what would be more beneficial is a more complex hello world app than the todo list. One that expresses the flexibility of Backbone's minimalism, along with the larger out-of-the-box functionality of Ember. I'm personally in the Backbone camp, but it would be easier to let the user decide what is best for him/her.

Isn't Knockout simpler than either one?

  In my experience, there's very much a need for a controller when writing even 
  moderately complex apps. You're presented with several options:

  1. Write controller code in views
  2. Write controller code in models
  3. Write controller code in a router
  4. Write your own controller infrastructure

  If you care about separation of concerns, none of these options are really 
  acceptable.

I care about separation of concerns when it's limiting the program complexity, and I don't have any problem with 3. Routing code is very lightweight, and it's sometimes beneficial to associate it with controller code -- those concerns are closely related, and not often referred to separately. In backbone, it's very easy to split a router into many (controller-style) files. If others have experiences to the contrary, I'd be interested to hear them.