[dts]

One thing that jumped out at me pretty quick in comparing the two implementations in jsFiddle is that with ember every property is set with an individual call rather than passing in an object of properties to change. Here is a version with backbone using individual set calls with a notable dip in performance: http://jsfiddle.net/6rvkC/

Is this limitation in ember because of the computed properties? Would changing this even help?

[wycats]

Interestingly, not really, because the Ember run loop implementation coalesces multiple calls to set, so using setProperties (which allows you to pass in multiple properties at once) doesn't really affect performance much.

It's one of the first things I tried, in case there was a bug in the run loop code that caused the re-render to happen multiple times.

[bcrescimanno]

I think it's worth noting, that Backbone (as expected, I imagine) gives you a little more rope to hang yourself with here. To me, that's a great highlight of how the frameworks differ in their approach. "Perfectly written" Backbone code is significantly faster; but, if you (perhaps unknowingly) take a slower path, Backbone isn't going to do anything to make it faster. Not advocating one approach over the other; just pointing out the juxtaposition.

[jashkenas]

Quite, and it's also worth noting that by relying on a "runloop" to defer your renders, you're giving up synchronicity in your data changes -> ui updates when you don't necessarily need to (a very common source of dev bugs in SproutCore 1).

[bcrescimanno]

Not having worked with SproutCore, I honestly can't comment on whether it introduced more bugs. Working with anything async is always going to introduce some complexity; but given the poor DOM performance on low-end devices, deferring rendering is often a very helpful concept.

I'd be interested to hear what type of bugs were common in this scenario; my understanding of the runloop is that after the DOM update (at the end of each loop) the UI should reflect the application state.