DOM Templating and Interpolation


Prior art

<rant>The future is so not evenly distributed

Tons of technologies (still, always) floating around for solving this banal (bikeshedding?) issue. Nu, evolution (>1,000 revisions!?). But what irks me is the appaling variance in… let’s call it “maturity”? And don’t get me started on their adoption distribution/demographics.

Nevertheless, after wading through NPM (where any common search produces infinite results — is this a thing already?), I’m still uncomfortable with the state of the art — which seems to be Transparency, or Pure, or Rule? — and considering forking/writing my own (aka yet another)!

(Contemplating: in a distant future, will they be as horrified, with things I now consider “neat”, as I am with five year old abominations, like, say, JsRender? ;o)


Client-side is different

“Isomorphic” JavaScript is a pile of hooey. Yeah, it’s the same rotten language (actually, we use CoffeeScript ;o), but so what? Utterly different tasks.

I’ve already “solved” server-side templating: see HTML templating: CoffeeCup, Teacup… Double Macchiato. Client-side is a different story. [Explain.]


Rough attempt at classifying the various mechanisms, and evolutionary stages:

  1. HTML generators: server-side (originally, and typically), output is one string, serialized DOM, final state representation.
  2. “Inverting the sock inside-out”: from HTML strings embedded in program code, to code embedded in an HTML document.
  3. String interpolators, aka “logic-less”
  4. “Logic” languages
  5. (SS DSLs — see HTML templating with Double Macchiato)
  6. DOM populating: map or merge data onto the DOM. (“No HTML on the wire — only JSON”, and “the DOM is the model!”)

DOM pupulating

[Explain why evolutionary step over interpolation based paradigm. HTML <template> used as DOM, not string!]

Dreamcode first

Simplest usecase: object

  1. Preparation phase on server-side, rendering HTML:
    {h2,li,ol,p,template}=require 'double-macchiato'
    div '#here',->
    	h2 'Initially'
    	p 'Rendered.'


  2. Then, client-side, repopulate that DOM:
    $ '#here'
    .fill data:
    	p:'Fill me up.'

Automatic iteration

  1. ol ->li empty

    If data contains arrays, then:

    $ 'ol'
    .fill {data}

    will render:


HTML templates

  1. Or using HTML <template>, which the browser will automagically parse — no string interpolations:
    ol '#here'
    template ->
    	li ->
    		h2 '.title'
    		p '.description'


    h=$ '#here'
    h.fill # Template next to container. (h==$ @, but too obscure.)


  1. (Or “li ‘.event’,->h2();p()” and use longer selectors, “.event h2,.event p”, to style them, instead? Nu, CSS cascading issues… we won’t get into here.)
  2. Absolutely no need for looping or conditional “logic” in template: write these in our preferred programming language instead — CoffeeScript! Keep content (or semantic structure, in template’s case) in HTML.
  3. But, what’s in “data”? List of events, an array of objects, obviously. [What about recursion?]
  4. [Hide distinction between populating visible vs shadow DOM?]
  5. [Also, an inverse operation, say “scrape”, would be so cool! Especially since I’m big on contenteditable. Examples?])


  1. Neat if keys were actual CSS selectors indicating where values should be interpolated, but… limitations? Complications?
  2. Apparently, I want an explicit mapping so as not to persist data with CSS selectors in its keys: separation of concerns — selectors encode presentation (structure), not semantics. (Don’t I? I’m not sure, because HTML (which is what CSS selectors describe) is ideally content, not presentation, so selectors should have worked? Ouch, that’s “presentation” in the styling (CSS) sense vs “(re?)presentation” in the state (REST) sense!)

And the winner is…

[Transparency does the render nicely with “default” directives auto-detecting element/class/ID/[data-bind]?; Rule does full(?) CSS selectors right (actual DOM reliance, appropriately?), but, directives again; and Pure, neither?]

[But, Transparency’s implementation, if indeed parses HTML, as opposed to Rule (I think!?), sucks! I don’t care about Node, and browser has already parsed my template! And DOM already does CSS selectors!]

  1. Transparency
    1. They call it “zero configuration” (what does it even mean, in this context? what would non-zero configuration be?), but the data must either be structured to match the DOM “template” — implicitly configuring the mapping — or “directives”, viz configuration, need to be explicitly provided. WTF? [I’d rather not persist data structured isomorphically to its DOM: it’s the presentation model, not data model.]
    2. Maps keys to DOM elements, class, ID, and… attributes? But, how?
    3. Iteration is automatic (but requires container). Recursion?
    4. Similar/related: fill
  2. Pure is purely horrible: neé 2008, presumably preceding Transparency, seems to have lost their way: shape configuration (“directives”) is convoluted, and the implementation regresses to string interpolation?! [But, innerHTML used to be a performance thing?]
  3. Rule?


Comments are closed.