[bemmu]

Am I missing something on why you can't just include your "templates" as display:none snippets of HTML and then .clone() them from the DOM and change the fields as needed? Perhaps my needs just haven't been complex enough to need a JS templating engine.

[ricardobeat]

There is a proposed standard called Web Components[1] that uses an inline-HTML approach (introducing the <template> element). Similar templating is used by Google's Angular.js, Knockout.js and other frameworks that implement observables/view-model binding.

[1] http://www.w3.org/TR/2012/WD-shadow-dom-20120522/

[sisk]

From an accessibility standpoint, this is a bad idea. Not that long ago, you had to make considerations for clients without CSS support (e.g., text-based browsers or screen readers). Across the board, things have gotten significantly better but there is still the issue of a stylesheet not loading (and mixing markup and CSS isn't great so that shouldn't be considered a reasonable alternative).

If a renderer comes across a script tag it doesn't know how to parse (e.g., a script of type `text/template`), it doesn't do anything with it, however it remains the responsibility of the markup renderer and, therefore, you're not relying on something else (CSS or JavaScript) to hide it.

[ricardobeat]

Not really, if you add style="display:none" inline, or use the `hidden` attribute, it will be correctly ignored by all screen readers.

<script type="whatever"> is mostly used because it's completely ignored. It's safely hidden, difficult to be accidentally messed with, and doesn't take parsing/rendering time from the browser.

[sisk]

Right but, as mentioned, inline styling is mixing markup and styles so it's best avoided (plus you're still relying on CSS to hide the content).

Regarding the `hidden` attribute, there is no support for it in IE (at least up to and including 9).

[sopooneo]

I know a lot of people argue against mixing markup and styling. As one of those, and since you seem well informed, how do you feel about the various css frameworks like bootstrap where the class names are essentially style descriptions?

[mmahemoff]

This can work, it's just a slightly more complex programming model, as it couples the template population code with the DOM structure. Whereas a template is effectively a cleanly-defined API in which you just pass it a set of key-value pairs.

DOM manipulation has traditionally been slower than innerHTML, which is another reason people might have shied away from this approach. I believe the performance gap is no longer clearcut though, so the argument may not hold for recent browsers at least.

[lincolnq]

I use a JS templating engine (Handlebars with compiled templates).

When you have 3- or 4-level nested templates with 50+ fields to fill in, it's much easier to write (and especially to maintain) the snippets of HTML with {{name}}-type template tags, rather than writing the code to query the DOM and replace elements as needed. Especially if you have a designer who's comfortable manipulating HTML elements but allergic to JavaScript.

[MatthewPhillips]

50 fields in a single template??? I use the parents technique because it punishes you for making gloat decisions like that.

[fla]

Wondering the same here. And what about caching the template library?