Google is killing the open web, part 2

Original Article ↗ Hacker News Discussion ↗

XSLT deprecation: usage, impact, and backward‑compatibility

  • Many commenters see XSLT-in-browser as niche and “dead”; others show concrete uses: RSS/Atom and podcast feeds, sitemap and government/regulatory sites, XML-based hobby sites, IoT devices exposing XML+XSLT, document/report viewers, and simple templating for non‑programmers.
  • A recurring argument: even if usage is small, the web’s “contract” was that standards-based content would keep working indefinitely. Removing a standard feature is viewed as a precedent that erodes trust.
  • Others counter that backward compatibility itself has a cost; if a feature’s usage is tiny, removing it can be justified.

Security, maintenance, and cost–benefit

  • Pro‑removal side: libxslt is old C code, a frequent source of security reports, and expensive to maintain; the maintainer quit under unpaid bugfix pressure. Keeping unused, complex code increases attack surface.
  • Critics respond that “security” is overstated or misused: XSLT has memory‑safe implementations and could be sandboxed or shipped as a WebAssembly/JS polyfill bundled with the browser, largely eliminating native-risk without breaking sites.
  • Disagreement over process: some feel Chrome pushed “intent to remove” and code changes before properly quantifying usage or understanding key cases (e.g., podcast feeds), contrary to Google’s own deprecation guidelines.

Comparisons with other web features

  • Opponents note XSLT’s usage is reportedly higher than various newer hardware APIs (WebUSB, WebSerial, MIDI, WebTransport) that browsers are eager to add and keep; they see inconsistency in invoking “low usage” only for older XML tech.
  • Defenders reply these APIs can’t be polyfilled and enable genuinely new capabilities (device setup, education, debugging), whereas XSLT transformations can be done on servers or in JS.
  • FTP and Gopher removals are cited as precedent. Some argue they were more widely used than XSLT but still rightly removed; others say FTP never got a proper successor for directory‑style browsing.

Standards process and Google’s influence

  • Several stress that removal was proposed within WHATWG with support from Mozilla and Apple; it’s not purely a unilateral Google move.
  • Nonetheless, Google’s dominance and its speed in landing Chromium patches make people see this as symptomatic of a browser‑vendor‑driven web, where implementor convenience outweighs user and author needs.
  • There is concern about Chrome moving to a partial Rust XML parser, seen by some as a signal that even standards‑compliant XML support may shrink.

Alternatives, polyfills, and RSS/Atom usability

  • Multiple people suggest that RSS/Atom feeds could be made friendly with JS and CSS embedded in XHTML namespaces, or via JS XSLT polyfills.
  • Critics argue that:
    • This breaks “truly static” sites and very constrained devices.
    • It forces authors to learn more complex JS instead of simple declarative templates.
    • It degrades the experience for non‑technical users who click feed links and see raw XML.
  • Some propose that browsers should instead offer first‑class, built‑in RSS/Atom rendering, which would obviate XSLT here, but they doubt such support will materialize.

Broader “open web” and philosophy debate

  • One camp: removing XSLT is a routine pruning of obsolete complexity and narrows the API surface, which can even help new engines like Ladybird.
  • Another: it exemplifies a shift from the web as a durable document network toward a brittle, app‑delivery platform optimized for ads, telemetry, and proprietary ecosystems, with backward compatibility and user control treated as secondary.