HN Distilled

Essential insights from Hacker News discussions

Show HN: JavaScript-free (X)HTML Includes

Original Article

Hacker News Discussion

Here's a summary of the themes from the Hacker News discussion:

Google's Role and the Removal of XSLT

A significant portion of the discussion revolves around Google's stated intention to gate XSLT behind a flag in Chrome and their request to remove it from the web standard. This action has sparked debate about the power of browser vendors and the process of standardizing web features. Some users express surprise and dismay that such a feature can be considered for removal, while others acknowledge that if major browser vendors don't support a spec, it becomes "essentially a hypothetical."

  • "Google have also asked for it to be removed from the standard." (shakna)
  • "I find it bizarre that Google can just ask for a feature to be removed from standard and nobody bats an eye." (SnuffBox)
  • "Although Google, Mozilla and Apple are all in favour of removing it, there’s been a lot of backlash from developers." (chrismorgan)
  • "standard is essentially the consensus of the major browser vendors; a spec which all of Chrome, Safari and Edge don't implement is really just a hypothetical." (esrauch)
  • "this is a weird way to try to stick it to them." (johncolanduoni, referring to developers disliking Google)
  • "I think their stated reasons - that libxslt is a security disaster zone for an obscure 90s-era feature - is earnest even if its not actually in the broader web’s best interests." (johncolanduoni)
  • "Even 'champion of the web' Mozilla is on board. Tells you exactly what you need to know." (ekianjo)
  • "By “started talking about it this month” I meant this specific advocation for removing it. Yes, it’s been talked about for years, but this time it’s specific." (chrismorgan)
  • "It's hard to tell what will break without being able to turn it off and see." (Quote from GitHub discussion about Chrome working on removal)

XSLT's Specification Versioning and Implementation State

There's a clear point of confusion and discussion regarding which version of the XSLT specification is relevant to the current browser implementation and the state of ongoing development. Many note that browsers have largely stuck to XSLT 1.0, which is quite old, while the standard has evolved to XSLT 3.0. This discrepancy leads to a "Catch-22" where the standard is outdated but implementations are not being updated, and conversely, the newer spec isn't implemented. The issue of "abandonware" implementations is also raised.

  • "And the reason for that is, the spec is still at XSLT 1.0, which is super old, and current implementations are effectively abandonware. Catch-22?" (notpushkin)
  • "The spec is at XLST 3 right now." (ekianjo)
  • "Browsers only implement XSLT 1" (abraham)
  • "I believe the spec is at XSLT 3.0 but no browser actually implemented past XSLT 1.0 (not 100% sure - almost nobody cared about this feature last month so hard to find good docs on support)." (johncolanduoni)
  • "even outside of browsers barely anything supports XSLT newer than 1.0" (arccy)
  • "Yeah, sorry, the XSLT spec is at 3.0 right now of course, but the browsers don’t implement it, and the WHATWG HTML Living Standard only mentions XSLT 1.0." (notpushkin)

Perceived Usefulness and Alternatives to XSLT

Several users express appreciation for XSLT's capabilities, particularly its strength in declarative, non-JavaScript templating and document transformation. Some lament its lack of adoption and propose new ways to use it, even suggesting compile-to-XSLT languages. Others compare it unfavorably to modern JavaScript-based solutions (like React with build steps) or suggest that CSS can handle some of XSLT's simpler display tasks. There's also a recurring theme of XSLT's complexity and the difficulty of maintaining XSLT code.

  • "I find it bizarre that Google can just ask for a feature to be removed from standard and nobody bats an eye." (SnuffBox)
  • "so it's time to use XSLT more" (kome)
  • "If I understand correctly, Mozilla and Apple don’t really want to support it either." (notpushkin)
  • "It doesn't seem weird at all to me: standard is essentially the consensus of the major browser vendors; a spec which all of Chrome, Safari and Edge don't implement is really just a hypothetical." (esrauch)
  • "Most of whom had never heard of XSLT before today - some were likely born after it had faded into obscurity." (johncolanduoni)
  • "XSLT is widely used, for example by the US congress" (sunaookami)
  • "It is quite complex, until you compare it to the complexity of what now solves this problem (e.g. a build step with React and webpack and javascript absolutely required on the client-side). As the OP ably demonstrates, XSLT provides a declarative, non-javascript, non-build way to solve the basic HTML component problem." (simpaticoder)
  • "React supports rendering to HTML ahead of time (SSR) which doesn't need any client-side javascript, and this is a prominent feature of most frameworks using React." (AgentME)
  • "Both XSLT and React can be used for this except React can additionally do a bunch of other stuff that does use JS and that XSLT can't do." (throwaway290)
  • "Whereas XSLT is not a general purpose tool in the same way, and so needs to be maintained in addition to Javascript and anything else that exists." (MrJohz)
  • "My guess there is that it's just not an intuitive way of manipulating and templating data in comparison to more traditional HTML templating libraries." (MrJohz)
  • "React's main thinh is client side reactivity, something that xslt doesn't offer. A closer comparison would be a templating engine that does statuc conversion to html." (bawolff)
  • "There are usage numbers." (panos, referring to the decision to remove XSLT)
  • "I have concerns. I kept this up to date historically for Chromium, and I don't trust the use counters based on my experience. Total usage might be higher." (stephen)
  • "even if the data were accurate, not enough zeros for the usage to be low enough." (dan)
  • "We have a history of security bugs, etc." (emilio)
  • "Yeah, that was a big deal" (stephen)
  • "Yeah we get bugs about it and have to basically ignore them, which sucks" (mason)
  • "people do use it and some like it" (brian)
  • "I used to do this in the 2000's era, there was a lot to love about it. At the time though the IE engines were far more complete and less buggy than others with various XML features." (raggi)
  • "The stylistic includes and certain content (e. g. a site map) can be embedded in the XSLT itself. It is not quite a templating engine. XSLT is a part of a semantic engine." (Mikhail_Edoshin)
  • "I'd point out you can do the same thing with CSS" (bawolff, providing an example using CSS for display)
  • "This latter part is why I've reached for XSLT in the past. Most recently was to convert an RSS feed into a styled page with instructions at the top. Templates and xpath can really transform a document." (8organicbits)
  • "You end up with a really bad waterfall where it can take a long time for a page to load because it's going back to the server constantly, whereas if you did it on the server it would be a single round trip." (b_e_n_t_o_n)
  • "I wish external entities were enabled in browsers (*), and not entirely disabled, like they are now." (myfonj)
  • "My hard-won judgement from using XSLT is that there were partisan representatives from every different programming language paradigm on the XSLT standard committee, and each one of them was able to get just enough of to showcase what was special about their own paradigm into the standard, while strategically sabotaging all the other competing paradigms to make them look foolish, but not enough features of coherency to actually get any work done, or lord forbid synergistically dovetail together into a unified whole." (DonHopkins)
  • "I have 1 "big" xsl file in a project I maintain. I have fixed an issue this year. I have tried to use chatgpt prompt. The scope was perfect: I had the buggy xsl, the buggy result, the expected result and a clear explanation. It generated syntactically correct code (almost) that did not work because chatgpt does not understand." (reacweb)

Security Concerns and Maintenance

Security vulnerabilities, particularly within libxml2 and its association with older XSLT implementations, are cited as a primary reason for Google's stance. Users mention past security bugs and the difficulty in addressing them, leading to the current situation where browsers might ignore reported issues. The complexity and potential for "logic bombs" in XML processing are also brought up.

  • "The origin story of whatwg is that Apple, Mozilla and Opera decided that W3C wasn't making specs that they wanted to implement, so they created a new working group to make them." (esrauch)
  • "I think their stated reasons - that libxslt is a security disaster zone for an obscure 90s-era feature - is earnest even if its not actually in the broader web’s best interests." (johncolanduoni)
  • "Partly, there's increasing attacks against XML. And also, libxml2 has said "no" to security embargoes altogether. [0] They might well consider there to be 0-days waiting in XSLT." (shakna)
  • "emilio: we have a history of security bugs, etc. stephen: yeah that was a big deal mason: yeah we get bugs about it and have to basically ignore them, which sucks" (emilio speaking to stephen and mason)
  • "XML "logic bombs" happens when the parser expand entities eagerly. If a parser does that one can easily assemble an enormous entity that will eat up all the memory. But a more sophisticated parser won't expand entities right away and thus can merely reject oversized ones. It is really a minor issue." (Mikhail_Edoshin)

Historical Context and Comparisons to Other Technologies

Users draw parallels between the XSLT situation and other web technologies that have faced similar challenges or been superseded. HTML Imports and the evolution of Web Components are brought up as examples of technologies that struggled with adoption or integration. The early days of the web and its reliance on SGML are also discussed, as is the past reliance on technologies like XULRunner.

  • "I remember admiring the intent of XSLT when it was born. And how difficult it turned out to be to write; using XML framing makes it terse/verbose/arcane, eg. when compared to the compactness of regex/subs." (msylvest)
  • "Why didn't HTML imports stick around? https://web.dev/articles/imports [link removed]" (xnx)
  • "The moronic Web Component cabal got their hands on it and trashed it by forcing it to rely on JavaScript, thus ensuring it would never get support." (lloydatkinson)
  • "For a long time web components generally built on four standards: Custom HTML elements, Shadow DOM, HTML imports, HTML templates. Eventually it became clear some browsers were not going to implement and the design of HTML imports was better handled be ES modules." (abraham)
  • "HTML Imports were redundant, since you need JavaScript to bring them alive anyways" (bapak)
  • "I think the problem wasn't that browsers (specifically Firefox and Safari) were opposed to the idea of html includes in general, but they didn't like the specific proposal, in large part because it still required javascript, and added a lot of complexity for little to no benefit." (thayne)
  • "HTML Imports was part of the initial set of the web components specs, there's no "cabal" or whatever that got its hands on it, and it didn't rely on JavaScript, not in the way you're probably referring to. It was only opposed because it was separate from the JS module system, not because it relied on JS." (spankalee)
  • "It was rejected because it needed JS to even work." (MortyWaves)
  • "This is really, definitely cool, but it's important to remember that content added via CSS is purely decorative. It can't be interacted with, which is a major issue for assistive technologies like screen readers." (egeozcan, critiquing CSS as a replacement for XSLT)
  • "This is how the simplest variant of SGML (or XML) entities have worked since 1986: ... HTML was envisioned as an SGML vocabulary from day one." (tannhaeuser)
  • "XULRunner (Firefox, Thunderbird, Songbird, Miro, Joost, TomTom Home, etc) abused XML external entities in language specific DTDs for internationalization / localization." (DonHopkins)
  • "This reminds me of Symphony CMS, which is XSLT based. Cool concept but not entirely practical in my experience." (mjaniczek)
  • "What's the whole point of bending over backwards to be "JavaScript-free" when the chosen alternative is using something as half-assedly hamstrung and counterintuitively crippled and mind-bogglingly rube-goldbergesque as XSLT, that tries to be all things to all people, thus satisfying no-one?" (DonHopkins)