agAST: A counter-proposal to dom-parts?

[conartist6]

I read Justin's recent blog post about a DOM templating API, and I wanted to chime in on the discussion because I've been researching this topic quietly on my own for several years now.

While the DOMParts solution solves the problem but only when HTML is the thing being templated, I've built a document system called agAST which solves the problem for any and every possible language that you could want to template. You get a solution to the problem that works for HTML, JS, CSS, JSON, XML, GraphQL, JSX, Python, Java... you get the idea, it works for anything.

Here is what this looks like for JS:

let js = buildTag(jsParser);

let tree = js`fire('event', js.Expression`true`)`;

// We can always print the textual tree as if this was just a text interpolation
printSource(tree) === `fire('event', true)` // true

// We can also support random named reads (and writes) in logn time
printSource(tree.get(['statements', 0, 'expression', 'callee'])) === `fire` // true

This works because tree is (a thin OO Proxy facade around) an immutable collections of plain JS objects and arrays -- structured more or less as a marriage of a syntax tree and a btree. Also because of the jsParser, which needs to be a special kind of parser that is aware of the possibility of embedding holes (gaps in the input) so that it works with buildTag.

Is this interesting to the web components team? If an API like this was in common use across the ecosystem, would it have any impact on what an optimal DOM-parts design would look like?

[conartist6]

To give you an idea of how scary general this is, it also satisfies the requirements of the JSSugar proposal

[Westbrook]

If you're interested in gathering feedback, it might be useful to share something in the form of a more complete example. In that most of the templating that has been discussed to date have been DOM-centric it could be useful to start there?

[justinfagnani]

I second @Westbrook's comment. The thing that makes DOM Parts useful is that they attach to the DOM and enable targeted updates. What actually updates the DOM here?

[conartist6]

Yeah, you're quite right, nothing updates the DOM here. It wasn't and isn't my personal design goal to build a full replacement for lit-html or Solid.

Since you're creating a low-level/high-level split, I think it should be the case that the greatest advantages would be achieved when the low-level implementation has the broadest range of different high-level uses.

I just wanted to point out that some of the problems like how to store parse results pre-interpolation are indeed more general.

[justinfagnani]

The lower level of the templating proposal is DOM Parts with attach settable ranges to the DOM. The higher level is the template syntax.

[conartist6]

I thought about it some more.

The system I would propose is closer to how React works, with a JS-land shadow-DOM which is designed to be easy to sync back to the native DOM. In terms of capabilities for JS it solves the problem of how to declaratively describe a the contents of a <template> or to (in JS) declaratively specify a set of changes that you want made to the DOM

I designed my DOM tree with a heavy dose of inspiration from Immutable.js. The tree nodes are deeply immutable and writes create trees that have structural sharing with each other (at the node and sub-node level). This makes it cheap to hold the before and after trees so that you can run a diffing algorithm to execute only the necessary changes and recomputations to the mutable structure, a design that React has proven can work well.

To make diffing fast my system gives each node a hash computed from the combination of its semantic and syntactic structure, so if any subtree's content has the same hash on either side of a change, then we know that we don't need to update that part of the native/mutable DOM. The hashes also allow the nodes to be transmitted over the serialization boundary using a post-order traversal strategy.