Re: [WICG/webcomponents] [templates] A declarative JavaScript templating API (Issue #1069)

justinfagnani left a comment (WICG/webcomponents#1069)

@mizchi 

> I'm prototyping a UI framework and came across this discussion. Let me offer a few comments.
> 
> Based on tagged template literals like lit-html doesn't seem like a good idea. Tagged template literals provide sanitization for templates, preventing XSS by ensuring that content doesn't exceed the bounds of string embedding.
> 
> In the case of tagged template literals, the ECMA262 specification makes it difficult to extend beyond alternating between split strings and values, and parsing as a tree structure remains the responsibility of the UI library.

Yes, parsing is the responsibility of some library or platform code. In this case I'm proposing that the platform uses the existing HTML parser to parse the template string contents and create a TemplateElement with DOM Parts, from which you can clone to a DocumentFragment with DOM Parts: https://github.com/justinfagnani/dom-templating-api-proposal/blob/main/EXPLAINER.md#template-processing-and-rendering-model

> UI libraries that use React or JSX require a specification that directly accepts parsed DocumentFragments for diffing, otherwise there's no incentive to use them.

Diffing libraries nearly universally do _not_ want a real DocumentFragment for diffing because the cost of creating real DOM nodes is far to high for this. They instead use "lightweight" node representations like React's VDOM nodes. But even those are heavyweight compared to not having a bunch of those temporary node for each static element at all, which is why the proposal I posted works with template cloning and value-diffing.

> I think what's needed at the DOM API level as a more general primitive is an API that goes in the opposite direction to MutationObserver . In other words, a protocol that accepts an array of `MutationRecord`s and applies them in batches. (How to represent the cumulative difference in node indexes during batch insertion is open to debate.)

This has been proposed before under the name "DOMChangeList" and that didn't make progress for several reasons:
- It's not clear that it would be a performance improvement. In fact there's reason to believe it would be performance negative.
- It required re-implementing a chunk of the DOM API in a way that doesn't require references to today's Node objects. That's a tough lift, and leaves use cases where you still do need to get a Node wrapper.
- It's goal of being able to apply changes in a non-blocking way was extremely complicated. Some of those ideas around how to make that work did make it into  the [Display Locking proposal](https://github.com/WICG/display-locking) which morphed into [CSS content-visibility](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/content-visibility), but those are still far short of sync updating the DOM while it's visible.
- It's not actually an ergonomic declarative API. It still requires a non-standard userland or compiled template syntax.

> I agree that Signal is a good abstraction, but given the history of JQuery, React, Svelte, Qwik, Solid, etc., I think it's dangerous to say it's a general solution for UI abstractions. If Signal were proposed, I think a more generalized AbortSignal would be in the realm of TC39.

Signals and AbortSignals are quite unrelated, aside from the coincidence of similar names. But I am not proposal a system that requires Signals, only one that [will work with them very well](https://github.com/justinfagnani/dom-templating-api-proposal/blob/main/EXPLAINER.md#fine-grained-template-part-updates). ie, DOM Parts can accept single values, like strings, or Signals. You can hold such an API like Solid or React, Angular, Lit, etc.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1069#issuecomment-3657596531
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1069/3657596531@github.com>