Chrome and Edge are removing XSLT: what breaks and what does not
Chrome and Edge are deprecating XSLT, prompting a wave of nostalgia and debate on HN about the road not taken in web development. Commenters reflect on the promises and pitfalls of XHTML and XML-based web technologies, lamenting their loss while acknowledging the practical reasons for their decline. The discussion delves into the evolution of client-side templating and the compromises made in the journey to modern web standards.
The Lowdown
The article discussing the removal of XSLT support in Chrome and Edge was, ironically, inaccessible due to a 503 Service Unavailable error at the time of review. However, the Hacker News discussion provided ample context, indicating a significant change in browser support for a foundational, albeit now niche, web technology.
- Chrome and Edge browsers are reportedly removing built-in support for XSLT (Extensible Stylesheet Language Transformations).
- XSLT, once envisioned as a powerful tool for client-side templating and modular web design alongside XHTML, enabled transforming XML data into other formats, including HTML.
- Many commenters expressed nostalgia for the XHTML/XML ecosystem, believing it offered a more structured and robust approach to web development compared to the current JavaScript-heavy paradigm.
- The decline of XSLT's relevance is attributed to the shift towards HTML5, the verbose nature of XML, poor tooling, and a lack of browser adoption for newer XSLT specifications (2.0 and 3.0).
- The deprecation is expected to impact some legacy systems, such as specific IIS reports that rely on XML+XSLT for rendering.
This development marks another step in the continuous evolution of web standards, prompting a thoughtful look back at the architectural choices that shaped the modern web and the reasons why certain technologies flourished while others faded.
The Gossip
XSLT's Glorious, Gone Days
Many commenters recalled XSLT and XHTML with a blend of fondness and regret, lamenting the web's shift away from structured XML-based approaches to HTML5 and JavaScript. They argued that XHTML's vision of schemas, client-side templating, and custom elements was a superior, cleaner path, leading to a 'horrid state of affairs' where developers now resort to complex frameworks to mitigate the underlying 'garbage' of the modern stack.
Why XSLT Didn't Win
While acknowledging XSLT's theoretical power, the discussion also delved into the practical reasons for its failure to achieve widespread adoption. Key factors cited include its difficult-to-comprehend syntax, poor tooling, steep learning curve, and the browsers' stagnant support (only XSLT 1.0 was widely implemented, ignoring 2.0/3.0). The perceived ease of JavaScript's learning curve and rapid evolution ultimately outmaneuvered XSLT in the browser landscape.
Modern Templating & Workarounds
Some commenters explored contemporary approaches to client-side templating in the absence of XSLT. They discussed using inline scripts that append elements, demonstrating how similar functionality can be achieved with modern JavaScript techniques, albeit with different mechanisms and potentially varied performance characteristics.
The Ironic 503
A recurring, lighter theme emerged from the article's own inaccessibility. Several users pointed out the irony of a piece discussing web technology deprecation being unavailable due to a server error (503 Service Unavailable). This self-referential humor served as a meta-commentary on the fragility and constant flux of web infrastructure.