String Templating Considered Harmful(flippinawesome.org)
flippinawesome.org
String Templating Considered Harmful
http://flippinawesome.org/2014/03/24/string-templating-considered-harmful/
13 comments
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/
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).
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).
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.
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.
I replied to this comment on the article itself, if anyone is interested: http://flippinawesome.org/2014/03/24/string-templating-consi...
This article was useful in identifying a number of different possible approaches to designing templates using JavaScript - digging in to the supporting links, libraries, and approaches was a good learning experience and brought me some new ideas about how to best build applications moving forward.
Specifically, digging into RActive it seems like it may be good for more straightforward data binding use cases. The template engine chooser was also new to me, and fun to run through: http://garann.github.io/template-chooser/
Specifically, digging into RActive it seems like it may be good for more straightforward data binding use cases. The template engine chooser was also new to me, and fun to run through: http://garann.github.io/template-chooser/
String templating is not type safe, operational transforms on trees (AST) can be type/structural safe.
Clojure https://github.com/cgrand/enlive
Python https://github.com/supervisor/meld3
Clojure https://github.com/cgrand/enlive
Python https://github.com/supervisor/meld3
Perhaps the title would better be, "I consider string templating harmful".
CoffeeScript's string interpolation is a nice templating alternative, especially with """ blockquotes.
Pretty good article, but I think it doesn't give enough credit to DOM templating systems being declarative.
i think your post does get a bit he-said she-said with the duelling benchmarks, but it's good to question things.
I hear you - my intention was more to explain the origin of the benchmark than to compare the different libraries/frameworks. The comparison I'm most interested in is Backbone (with templating) versus Backbone (with DOM manipulation), because it shows how dramatically you can improve performance by not continually generating HTML and overwriting the existing DOM.
I guess the technique we're using would fall under "DOM-templating" which the writer dismisses with four bullet points:
* less expressive
I somewhat disagree, and would also say that the only reason for having the extra "expressiveness" is to do things you probably shouldn't do in your template.
* you may need to avoid a flash of unbound content
But you may not!
* server-side rendering is hard or impossible without hacks
But I'd say that rendering string templates server-side is simply bad if you do not comprehend the HTML, so the "hacks" are worth it, and not really a big problem with -- say -- node.
* data-binding cruft
Simply disagree here -- make your data-binding "cruft" legal and it helps see what's going on in debugging.
So I'll stick with our "DOM-templating" approach. Good read though and thought-provoking.
* less expressive
I somewhat disagree, and would also say that the only reason for having the extra "expressiveness" is to do things you probably shouldn't do in your template.
* you may need to avoid a flash of unbound content
But you may not!
* server-side rendering is hard or impossible without hacks
But I'd say that rendering string templates server-side is simply bad if you do not comprehend the HTML, so the "hacks" are worth it, and not really a big problem with -- say -- node.
* data-binding cruft
Simply disagree here -- make your data-binding "cruft" legal and it helps see what's going on in debugging.
So I'll stick with our "DOM-templating" approach. Good read though and thought-provoking.
Using the phrase 'considered harmful' in the title of a blog post is considered harmful
From reading this, I get the feeling that the author has had very focused exposure to "front end" web application development. Particularly from his view on server side rendering vs. client side rendering. For one, his bullet points are hacks to support javascript heavy web applications. Something that most sites really don't need and could easily find antithetical to other goals (Search Engines anyone?).
Correct - I work primarily on the front end. The article is about creating rich interactive interfaces that perform well in the browser without sacrificing the ability to render initial pages on the server, something which (as falcolas notes) could have been made clearer.
String Templating Considered Harmful... for generating content client side.
An important sub-title which needs to be highlighted, as these arguments and micro-benchmarks do not apply to most people who use string templating server side.
An important sub-title which needs to be highlighted, as these arguments and micro-benchmarks do not apply to most people who use string templating server side.
I've been hearing progressively more noise around the DSL[0] approach lately though. The OSS options might not be competitive (or maybe they are?), but performant implementations definitely exist.
[0] https://wiki.python.org/moin/Templating#Template_engines_imp...
[0] https://wiki.python.org/moin/Templating#Template_engines_imp...
Very nice ... Ractive.js looks like it has a lot of potential, and I'll definitely give it a try.
> Because it only touches the parts of the DOM it needs to, you can write your templates in the way that makes the most sense for your app, without having to worry about the performance headaches of constantly trashing the DOM or the code headache of wiring up a plethora of view objects.
Huh, the solution he described is basically the technique I use in Mithril[1], except that Mithril templates don't need the extra HTML parsing step because they pretty much are the AST.
My bare-bones approach received some criticism here last week for not being "pretty" (for the "HTML is pretty" definition of "pretty"), but it allows better debuggability[2], and opens the doors for some interesting FP techniques, among other things.
Templating seems to be a hot button these days, but it's unfortunate that it's such a complex topic. Discussions about performance like this article are great, but it's hard for non-framework devs to keep all the other facets of template design in their heads when trying to evaluate the bazillion choices in the market.
[1] http://lhorie.github.io/mithril/
[2] https://github.com/lhorie/mithril.js/issues/16