The repaint overhead is the same for every system tested.
The benchmark evaluates the overhead of data book keeping for one class of problems (updating a bunch of bindings all at once). Just because the paint time in this particular example dominates doesn't mean that the benchmark is inaccurate, as many applications using some sort of data binding-ish technique are indeed dominated by JS rather than paint time.
> and as long as data binding is implemented in a sane manner, it is almost never the bottleneck.
Maybe for small apps.
Re:String Templating Considered Harmful
by rich_harris on Monday March 24, 2014 @01:35PM
(#7459722)
I replied to this comment on the article itself, if anyone is interested: http://flippinawesome.org/2014/03/24/string-templating-consi...
A fork of the fork from the article using async measuring: 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).