XSLT – Native, zero-config build system for the Web

Original Article ↗ Hacker News Discussion ↗

Reactions to the article and “grug” style

  • Several readers liked the goal (simple, zero-build web stack) but bounced off the caveman‑style prose, finding it distracting or hard to read.
  • A few found the tone fun or endearing; others said they stopped reading purely because of the style.

Browser support, versions, and deprecation risk

  • Multiple comments note that browsers only support XSLT 1.0, with no movement toward 2.0/3.0.
  • There is concern that browser vendors have discussed deprecating XSLT; some already prefer running transforms server‑side to avoid future breakage.
  • Practical notes: XSLT often doesn’t work when opening XML from file://; serving via HTTP is more reliable. Firefox and Chrome use different engines with different quirks and limited debugging.

Real‑world uses and success stories

  • Many war stories from early 2000s: mobile portals, WAP sites, interbank messaging, reporting systems, Google Search Appliance, Cocoon, XSLT‑based CMSs.
  • Modern uses include: styling Atom/RSS feeds, blogs built directly from XML+XSLT, game config/modding (e.g. one popular game), API documentation, interop pipelines, EXI‑compressed XML, CI pipelines and schema‑driven data generation.
  • Some praise XSLT for configuration‑driven transformations where non‑“full‑stack” staff can safely adapt outputs.

Developer ergonomics and DX

  • Common complaints: difficult to learn and re‑learn, poor mnemonics, multiple sublanguages (XSLT + XPath), verbose XML syntax, lack of good debuggers, hard to printf‑debug, confusing template priorities.
  • Namespaces and XPath are a recurring pain point; workarounds are seen as ugly.
  • Some compare XSLT unfavorably to Jinja/Mustache, React, jq, or general‑purpose languages with JSON libraries.
  • Others report it was mind‑expanding and a first exposure to functional programming, idempotency, and declarative transforms.

Performance and complexity

  • XSLT can be very fast for the right workloads, especially with good engines (e.g. Saxon) and keyed lookups.
  • But several users describe production incidents where naïve stylesheets had hidden O(n²) or worse behavior that only surfaced on larger documents; diagnosing and fixing these was painful.
  • Consensus: fine for simple sites and pipelines; complex, data‑heavy trees require careful design and sometimes better tools.

XML vs JSON/YAML and “what we lost”

  • Many miss XML’s schemas, namespaces, comments, mixed content, XPath/XSLT ecosystem, and standards maturity.
  • Others argue XML was over‑sold in the 2000s, misused as a universal solution, and became associated with bloated enterprise stacks and hardware XML appliances.
  • Debate around bandwidth and “bloat”: some say XML is heavier; others point out compression and EXI largely mitigate this.

Static sites and no‑build workflows

  • Several people are attracted to the article’s core idea: no JS, no build tools, just XML+XSLT served as static files that browsers transform.
  • XSLT is suggested as a way to get includes (navigation menus, templates) for small static sites without server‑side logic or generators.
  • Counterpoints: limited browser support and tooling, risk of future removal, and the fact that simple PHP/SSI or modern static generators are often easier to work with and host.