Live data from Hacker News

Backbone vs Ember

smus.com

41–42 of 42 posts

Re: Backbone vs Ember

#41

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?

Well, I can tell you about SproutCore developer's experiences with Ember's views: they're ripping them out of their apps.

About 10 months ago, Strobe was trumpeting the "Ember" model for views (auto-updating templates, heavy nesting, bindings everywhere) and a lot of SproutCore developers began to use it.

The bloom is definitely off of that rose. At the latest user group meeting three weeks ago, many developers spoke up about having to remove all of their template view code because the performance was absolutely terrible.

At this point, "Ember-style" template views have been relegated to a separate opt-in library, are only being recommend for lightweight read-only data, and the recommendation for developers to use them is being removed from SproutCore's documentation.

Re: Backbone vs Ember

#42
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.

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

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

Post reply on HN