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