

String Templating Considered Harmful - remotesynth
http://flippinawesome.org/2014/03/24/string-templating-considered-harmful/

======
lhorie
> 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/](http://lhorie.github.io/mithril/)

[2]
[https://github.com/lhorie/mithril.js/issues/16](https://github.com/lhorie/mithril.js/issues/16)

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

~~~
rch
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...](https://wiki.python.org/moin/Templating#Template_engines_implemented_as_Internal_DSL.27s)

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

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

~~~
peterhunt
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.

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

~~~
rich_harris
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.

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

------
sailfast
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/](http://garann.github.io/template-chooser/)

------
sitkack
String templating is not type safe, operational transforms on trees (AST) can
be type/structural safe.

Clojure [https://github.com/cgrand/enlive](https://github.com/cgrand/enlive)

Python
[https://github.com/supervisor/meld3](https://github.com/supervisor/meld3)

------
allochthon
Perhaps the title would better be, "I consider string templating harmful".

------
elwell
CoffeeScript's string interpolation is a nice templating alternative,
especially with """ blockquotes.

------
Bahamut
Pretty good article, but I think it doesn't give enough credit to DOM
templating systems being declarative.

------
AdrianRossouw
i think your post does get a bit he-said she-said with the duelling
benchmarks, but it's good to question things.

~~~
rich_harris
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.

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

