[magicofpi]

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?

[bcrescimanno]

There are some pretty legitimate concerns with Ember and large data sets right now as the treatment of those datasets tends to be fairly naive and linear. There are several people, myself included, who are working on ways to address that problem--but modifying a large collection, at the moment, can trigger the entire collection to re-render which can be extremely expensive.

FWIW, I'm not an expert on Ember.js or Backbone; just someone trying his hand at hacking the Ember.js code to work more effectively with collections (since some of the use cases I have would be impossible using the current methods of bindings and collections).

[learc83]

>modifying a large collection, at the moment, can trigger the entire collection to re-render which can be extremely expensive.

How large is large enough to cause problems?

[bcrescimanno]

It really depends on your environment and the complexity of the rendering tied to your collection. For example, on a fast desktop-class system with a collection that renders one element with 1 property, you can probably have hundreds (or maybe even thousands) of items in the collection before you start to notice slowdowns when the collections update. Working on lower-end and mobile platforms, those numbers change. Similarly, if you rendering is complex, it will take more time as well. All that said, there's really no "magic number"

There are definite workarounds such as setting up paging--but the simple approach of using Ember.js bindings to bind a collection to a template will fall to pieces as that collection grows.

[sbarre]

I would also like to know this. :-)

[tbatterii]

me as well.

[erichocean]

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.