Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control.
Angular also would not update the DOM as many times as the backbone example as it uses dirty checking to get around this problem.
Angular.js still suffers as shown by the optimization article I linked to in my post. These kinds of typical optimizations can and should be pushed out of the user's hands.
The same holds for dependent computed properties. If you change a dependencies many times in a row, the dependent property only reevaluates once.
1. It's not running Ember in production mode which is much faster.
2. It's running an older release candidate version of Ember.
3. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops.
I re-ran the benchmarks with the latest production mode Ember.js and removed the incorrect run loop usage got the following results:
https://gist.github.com/eviltrout/8058560
It's still slower than ReactJS but much less so than before. In fact it's now #3 in that benchmark suite behind ReactJS and Backbone (and much faster than ReactJS in the completing benchmark), although I wouldn't be surprised if the other frameworks were set up as incorrectly too.
At least according to this data, React and Backbone are the fastest. (Om is faster than vanilla React)
One suspects that with hand-optimization the other frameworks could be a lot faster, but the point of this post is that it is fast without hand-optimizations.
I'd be interested to see these numbers after doing `npm install react-raf-batching` and doing `require('react-raf-batching').install()`.
Example: Average code written in node.js is typically just as slow as, say, PHP (in fact node.js was 3x slower than php in techempower benchmarks). However, it has potential to be much faster when optimized whereas PHP doesn't reward such optimization almost at all.