One thing I noticed about the circle drawing jsFiddle is that it’s clocking each loop synchronously, which is… totally inaccurate because repaint can happen out

One thing I noticed about the circle drawing jsFiddle is that it’s clocking each loop synchronously, which is… totally inaccurate because repaint can happen outside of the JavaScript event loop. The proper way to measure the actual time taken to render the change is to clock the loop asynchronously at the beginning of the next iteration. A fork of the fork from the article using async measuring: http://jsfiddle.net/yyx990803/VrLjY/ http://jsfiddle.net/yyx990803/VrLjY/ It's easy to notice that the majority of the time is actually spent on the repaint and the difference between implementation becomes much less significant. The only takeaway from this benchmark is that innerHTML/DOM thrashing your entire view is slow, and as long as data binding is implemented in a sane manner, it is almost never the bottleneck. The arguments against DOM templating are, as the author admitted, pretty opinionated. Personally for me I much prefer working with real HTML and find it more readable. However, I do agree the real advantage of a virtual/parallel DOM implementation is the ability to render isomorphically on both client and server, and it is something most DOM-based templating solutions haven’t been able to properly address yet (although not impossible).