Backbone vs Ember

I would recommend the JS Jabber from this week over this blog post: <a href="https://news.ycombinator.com/item?id=3587689" rel="nofollow">https://news.ycombinator.com/item?id=3587689</a><p>Jeremy &#38; Yehuda touch on most of the issues in this post and you can hear the points directly from their POV rather than filtered through someone else.<p>Additionally it's interesting to hear that Jeremy &#38; Yehuda are at odds (philosophically) on several other issues which I think help to round out the ideas behind Backbone, Ember, and other projects both of them are involved in.

We're using both Ember and Backbone here at Square. Backbone has proven useful for small apps (<a href="https://squareup.com/retail" rel="nofollow">https://squareup.com/retail</a>) while Ember is an effective replacement for Rails when it's backed by a good JSON api.

Guh. A fun dive into politics, but I'm not such a big fan of Boris' conclusions, as you might imagine.<p><pre><code> &#62; Backbone by itself is not sufficient for building complex web apps. </code></pre> That bit is particularly galling ... It's one thing to opine about stated philosophy, and another thing to really look at how the rubber hits the road.<p>SproutCore/Ember (5 years worth of apps, major corporate backing): <a href="http://sproutcore.com/#application-slider" rel="nofollow">http://sproutcore.com/#application-slider</a><p>Backbone.js (1.5 years worth of apps, just plain 'ol open source): <a href="http://backbonejs.org/#examples" rel="nofollow">http://backbonejs.org/#examples</a><p>'nuff said.

Just thought I'd throw out SmartClient here:<p><a href="http://www.smartclient.com/" rel="nofollow">http://www.smartclient.com/</a><p>It's an example of what you get when you follow the "framework does everything but the kitchen sink" philosophy to the end and pile on feature after feature. (It's open source, too!) It's great if you need to hack together a "enterprisey" client and don't really care about style or extendability (rare but these requirements happen.)<p>The databinding support, controls, and the amount of stuff it does out of the box is absolutely incredible for a free open source framework. But, it's ugly as hell, bloated, and if you want to do anything off the beaten path, you're fucked. But it's a remarkable piece of engineering that goes under the radar (similar to OpenLaszlo) but also a cautionary tale for the Ember guys to not take it too far.

I'm particularly interested – if anyone has experience using Ember – about the concerns raised about Ember's performance with large amounts of data and "hairy custom view situations," as borismus puts it. Is Ember actually going to be slow when dealing with large data sets?

&#62; <i>In my experience writing Backbone apps, views are very primitive and tend to cause issues. There's no support for any sort of view nesting, which is totally critical for large applications with complex UIs. In contrast, Ember provides an easy way of nesting views inside one another.</i><p>I have run into this. It’s really frustrating, in Backbone.

<p><pre><code> 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. </code></pre> 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.

I see the difference as something like Django/Sinatra vs Rails. Backbone requires the developer to be more explicit, whereas Ember is more opinionated and performs magic behind the scenes as long as you follow the conventions.<p>On a practical note, my experience earlier this week suggests Backbone right now is far easier to get your hands dirty with. I was excited to use Ember, but I had a practical time constraint and discovered it's a rough ride right now, so reverted to Backbone for this task. There's really very few examples, unless you want to start diving into older Sproutcore docs and trying to figure out the diffs.<p>In contrast, Backbone has a wealth of articles and even design patterns and books. Of course, it's an apples-versus-oranges distinction with Ember being so much newer, but an important practical issue for developers to be aware of if they're deciding right now.

Ember is definitely an alternative to Backbone, but people should stop conflating Ember with SproutCore: the two frameworks are targeted at completely different types of apps.<p>FWIW, the SproutCore community has rejected the Ember approach for the kinds of apps SproutCore is meant for: large, desktop-style apps that need to run fast in modern web browsers. The supposed "features" Ember provides, like auto-updating templates, have proven to have such bad performance in existing SproutCore apps that developers have almost universally been ripping them out (this was discovered at the most recent SproutCore User Group last month).<p>Ember is an alternative to Backbone -- a 600 LOC micro-framework. That should tell you all you need to know about Ember's scope. (SproutCore is well over 20K LOC.)

I've been working with Backbone exclusively for the last six months or so, so don't know what other frameworks are doing with nested views. The OP marks this as one of Backbone's shortcomings.<p>I've been writing my backbone app effectively with nested views, where parent views pass relevant information to child views either through initialization or functions on the child view, while the child view "communicates" with the parent view through events that the PV can bind to.<p>I kind of like the idea of child views not knowing or caring who created them or why. I do this e.g. with buttons, forms, panels and subpanels, etc.<p>Is there a good resource for best practices here?

Boris, I dont know if it happens only to me, but your blog is badly rendered on my Chromium (Linux Mint): many many words are overlapped (like all the paragraph "I like..." under your photo). Everything seems fine in Firefox, I'll try with Chrome on Windows at work.<p>Edit: Chrome on Windows is ok, maybe there's something wrong on my Linux installation

I'll add my voice to those that would like some much better documentation from ember.js. I'm starting to finds some stuff on stack overflow but it has taken a while to find. A few things that would help tremendously when people get started:<p>-Examples of the built in controls(tab,select,textfield,textarea). There are only like 6 of them but when you find out they exist and are not documented they feel like 600. The sroutcore history amplifies this assumption.<p>-The fact that sub views(ie textfield) don't bubble but are really easy to implement by extending TextField. See: <a href="http://stackoverflow.com/questions/8646238/handling-blur-on-textfield-child-in-ember-view" rel="nofollow">http://stackoverflow.com/questions/8646238/handling-blur-on-...</a> (PS. Why is this? It seem silly that I can't do {{view Ember.textField change="parentview.change"}} in my views.)

Just to remind, there is also batman.js which is very similar to amber.js but more CoffeeScript oriented.

Isn't Knockout simpler than either one?

Over the past few weeks I've seen a number of Ember evangelists making claims about BB as 'hard to use' or 'suitable for small apps'.<p>I don't agree.<p>The fact is that BB is stable and has loads of documentation and live apps. Ember not so much.