String Templating Considered Harmful

> This AST is later combined with data (typically plain old JavaScript objects, or POJOs) to construct a lightweight data-bound ‘parallel DOM’, which can run in the browser or on the server. Through this, it is able to make smart decisions about how to update the real DOM in the most conservative manner possible.

> 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

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.

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.

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

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?).

Using the phrase 'considered harmful' in the title of a blog post is considered harmful

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/

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

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.

Very nice ... Ractive.js looks like it has a lot of potential, and I'll definitely give it a try.