Hacker News Reader

Comment by cedilla | Hacker News Reader

Sure there are examples of websites using XSLT, but so far I've only seen the dozen or maybe two dozen, and it really looks like they are extremely rare. And I'm pretty sure the EU parliament et. al. will find someone to rework their page.

This really is just a storm in a waterglass. Nothing like the hundreds or tens of thousands of flash and java applet based web pages that went defunct when we deprecated those technologies.

View on HN

Those had good rationale for deprecating that I would say don't apply in this instance. Flash and Java applets were closed, insecure plugins outside the web's open standards, so removing them made sense. XSLT is a W3C standard built into the web's data and presentation layer. Dropping it means weakening the open infrastructure rather than cleaning it up.

> This really is just a storm in a waterglass. Nothing like the hundreds or tens of thousands of flash and java applet based web pages that went defunct when we deprecated those technologies.

Sure, but Flash and Java were never standards-compliant parts of the web platform. As far as I'm aware, this is the first time that something has been removed from the web platform without any replacements—Mutation Events [0] come close, but Mutation Observers are a fairly close replacement, and it took 10 years for them to be fully deprecated and removed from browsers.

[0]: https://developer.mozilla.org/en-US/docs/Web/API/MutationEve...

They are definitely rare. And I suspect that if you eliminate government web sites where usage of standards is encouraged, if not mandated, the sightings “in the wild” are very low. My guess would be less than 1% of sites use XSLT.

You ignored the argument (though probably not intentionally). You talk about how many you've seen. But you probably seen way more and never realized

If there were that many, why do people only list the same handful again and again? And where are all the /operators/ of those websites complaining? Is it possible that installing an XSLT processor on the server is not as big a hassle as everyone pretends?

Again: this is nothing like Flash or Java applets (or even ActiveX). People were seriously considering Apple's decision to not support Flash on iPhone as a strategic blunder due to the number of sites using it. Your local news station probably had video or a stock market ticker using Flash. You didn't have to hunt for examples.

> If there were that many, why do people only list the same handful again and again? And where are all the /operators/ of those websites complaining?

I've spent the last several years making a website based on XML and XSLT. I complain about the XML/XSLT deprecation from browsers all the time. And the announcements in August that Google was exploring getting rid of XSLT in the browser (which, it turned out, wasn't exploratory at all, it was a performative action that led to a foregone conclusion) was so full of blowback that the discussion got locked and Google forged ahead anyway.

> Is it possible that installing an XSLT processor on the server is not as big a hassle as everyone pretends?

This presumes that everyone interested in making something with XML and XSLT has access to configure the web server it's hosted on. With support in the browser, I can throw some static files up just about anywhere and it'll Just Work(tm)

If the server behavior can't be changed, there's a couple JavaScript engines to do the rendering client-side.

Running a script that interprets a different script to transform a document just complicates things. What do I do when the transform fails? I have to figure out how to debug both XSLT and JavaScript to figure out what broke.

I don't have any desire to learn JavaScript (or use someone else's script) just to do some basic templating.

What does one do when transform fails right now? You have to debug both XSLT and a binary you don't have the source for; debugging JavaScript seems like a step up, right?

I used to be able to load the local XML and XSLT files in a browser and try it. When the XSLT blew up, I'd get a big ASCII arrow pointing to the part that went 'bang'. It still only kind of works in FireFox

  XML Parsing Error: mismatched tag. Expected: </item>.
  Location: https://example.org/rss.xml
  Line Number 71, Column 3:
  </channel>
  --^

Chrome shows a useless white void.

I enabled the nginx XSLT module on a local web server serve the files to myself that way. Now when it fails I can check the logs to see what instruction it failed on. It's a bad experience, and I'm not arguing otherwise, but it's just about the only workaround left.

It's a circular situation: nobody wants to use XSLT because the tools are bad and nobody wants to make better tools because XSLT usage is too low.

Reply on news.ycombinator.com