Show HN: JavaScript-free (X)HTML Includes

Browser & standards status of XSLT

  • Chrome is adding a flag to disable XSLT to measure breakage; some commenters initially misread this as immediate deprecation.
  • Google, Mozilla, and Apple all support removing XSLT from the HTML standard; only XSLT 1.0 is referenced there.
  • The XSLT spec itself is at 3.0, but browsers only ever implemented 1.0, and even non‑browser tools rarely go beyond 1.0.
  • Some see this as normal standards evolution (no implementers → remove), others as large vendors unilaterally killing features.

Security, maintenance & rationale

  • Pro‑removal arguments: old code (libxslt/libxml2) full of security issues, no embargoes, and an attack surface overlapping with XML parser bugs (entities, “logic bombs”, XXE).
  • Counterpoint: many of these problems are solvable with better defaults and limits; XML’s bad reputation is partly historical.

Developer reactions & real‑world usage

  • Some developers rely on client‑side XSLT for personal sites and niche domains (e.g., technical publishing, TEI, documentation pipelines) and feel abandoned.
  • Others argue that many vocal defenders had never used XSLT before, and that widely cited examples of “real usage” are overblown or already have server‑rendered HTML equivalents.

Client vs server transforms & performance

  • Concern: client‑side XSLT can cause request waterfalls (XML → includes → XSLT → assets), echoing early SPA “spinner” patterns.
  • Mitigations mentioned: caching static includes, embedding styles/templates in the XSLT, or running the transform in CI/CD or server‑side (PHP, Java, CMSs).

Alternatives & related technologies

  • CSS-only styling of XML can handle simple display but not templating, includes, or logic.
  • HTML Imports were abandoned as redundant and poorly integrated with JS modules; HTML Modules are suggested as a future direction.
  • Some wish browsers had safe external entities or a simple declarative “HTML includes” mechanism.
  • Others propose JSON + template engines (a hypothetical “JSLT”) as a modern parallel.

Ergonomics, complexity & tooling

  • XSLT is praised for declarative power (XPath, templates) and rich XML workflows, but criticized as verbose, unintuitive, and inconsistent across processors.
  • Several note that general-purpose languages (Ruby, PHP, JS) are often easier for transforms.
  • A few report mixed results using LLMs to write XSLT: good for syntax scaffolding, poor at nontrivial logic.