Filldom: DOM Templating and Interpolation

WIP…

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

<rant>

1. The future is so not evenly distributed…
2. Tons of technologies (still, always) floating around for solving this banal (bikeshedding?) issue. Nu, evolution (>1,000 revisions!?).
3. 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.
4. 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)!
5. (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)

Prior art

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?
4. …
5. Compare them!
   1. Rule, Transparency, Pure, Mustache et al?
   2. Comparisons must, but already in Wikipedia? See what's useful there.
   3. Links to relevant alternatives, features, syntax examples, table for comparison!
6. Pick winner, or write/adapt my own?
7. Add TL;DR section: winner I picked/adapted, and juicy example/s?
8. Consider dreamcode ideas, since seems I'll have to rewrite Rule: hide/merge iteration syntax, hide/merge template cloning with just applying to a DOM branch, etc?

Typology

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

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:
   		h2:'Dynamically'
   		p:'Fill me up.'

Automatic iteration

1. ol ->li empty

   If data contains arrays, then:

   data=li:['Lorem','ipsum','dolor','sit']
   $ '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' Client-side: h=$ '#here' h.fill template:h.next() # Template next to container. (h==$ @, but too obscure.) data:[ title:'One',description:'Foo.' title:'Two',description:'Bar.' ]

Selectors

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

Shape-shifting

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

Filldom

Bookmarks

…