The time is right for a DOM templating API

Original Article ↗ Hacker News Discussion ↗

Limits of Current Native Templating

  • Existing primitives (<template>, <slot>, Shadow DOM) are seen as too basic: they mostly do one‑time merges and lack built‑in reactivity or dynamic loading (<template src="..."> ideas).
  • <slot> behavior is tightly coupled to Web Components and JS; not a general-purpose, reactive templating system.
  • Declarative Shadow DOM (DSD) helps SSR and “no‑JS” trees, but still requires customElements.define for real components and has awkward ergonomics (e.g., template duplication per instance).

Reactivity, Signals, and Update Models

  • Many commenters argue a native templating API is blocked on agreeing what “reactive” means; TC39 signals are mentioned as a likely but not-final direction.
  • Some prefer React’s “update state and re-render tree” mental model (simpler, slower); others prefer fine‑grained dependency tracking (signals, DAG-like calc trees), but note the cognitive cost.
  • Suggestion: keep templating and reactivity separate, but the moment you want automatic updates you must pick an update model, and consensus there is lacking.

Performance, Virtual DOM, and Low-Level APIs

  • DOM-level templating is historically slower than string-based templating, which is why many stayed with strings.
  • Several want a native “virtual DOM patch” primitive (e.g., patch(node, vdom) or applyDiff(...)) rather than a full templating language, so frameworks can share a fast, native diffing engine.
  • Others note newer frameworks (Svelte, Solid, “signals-forward” Vue) deliberately avoid VDOM, so a VDOM-centric API might already be dated.
  • DOM Parts and related low-level proposals are seen as more realistic and generally useful than a full declarative template spec.

Syntax: JSX, Tagged Templates, and DSLs

  • Strong disagreement with the article’s “we know what good syntax looks like” claim:
    • JSX fans see “templates as expressions + JS control flow” as the winning pattern.
    • Others prefer HTML- or text-based templating (Vue, Svelte, Jinja-style), arguing JSX overuses map/ternaries and isn’t idiomatic JS.
    • Lit’s tagged template literals are liked by some (“just HTML-ish strings”), criticized by others as a custom, non‑HTML language.
    • Some advocate a richer host language/DSL (Kotlin/Compose-style builders) rather than standardizing JSX or string templates.

Web Components and Declarative Shadow DOM

  • Mixed to negative sentiment on Web Components:
    • Seen as over‑engineered, spec-heavy (dozens of related specs), and poorly aligned with everyday component needs.
    • Pain points: styling across internal structure, form participation, ergonomics of slots and templates, and needing JS glue even for simple use cases.
    • Others counter that the core model—extending HTMLElement, lifecycle callbacks—is straightforward and DSD enables fully declarative trees for some cases.

DOM Ergonomics and jQuery

  • Several complain that native DOM APIs remain clumsy compared to jQuery’s fluent, composable interface.
  • querySelectorAll + NodeList’s limited methods force Array.from/spread boilerplate; iterators help but still feel awkward.
  • Some nostalgically suggest “just standardize jQuery-like APIs”; others argue jQuery’s scope is too broad and its cross‑browser shims are obsolete.

Platform Complexity and Standardization Strategy

  • Concern that every new high-level feature bloats the platform and makes alternative engines (e.g., Servo) harder to build and maintain.
  • Some argue the web should add fewer “framework-level” abstractions and more low-level, generic capabilities (DOM diffing, snapshot APIs, iterator helpers, compositional JS features).
  • Others respond that the platform has always evolved by gradually absorbing userland patterns (e.g., querySelector, classList), and templating/reactivity could be the next such layer—but only if the long-term costs and backward-compat implications are carefully weighed.

Diverging Views on Native Templating Itself

  • Supporters: native, safe templating could cut React‑scale JS payloads, improve CPU/bandwidth usage, avoid unsafe innerHTML, and make “HTML file + browser” workflows viable again.
  • Skeptics: frameworks are still rapidly evolving; standardizing a particular model (syntax + reactivity) now risks locking in today’s fashion and repeating Web Components’ misalignment with real-world practice.