LOL, what?? I used to work in shops, circa early 2000's, where 100% of the report-generation was driven by XSLT. I'm pretty sure it had massive corporate penetration at some point, especially when riding along with Microsoft's pervasive-at-the-time support of the standard. And I'm sure it's still got decent penetration out there.
[–] xp84 3 days ago
[–] randallsquared 3 days ago
But the original statement being objected to was "never got off the ground", and while you can say many things about IE6, that isn't one.
[–] xp84 2 days ago
[–] pmarreck 2 days ago
[–] cowlevel 3 days ago
IMO the main use of client-side XSLT was making people say "what the-?" when they viewed source, because they'd get an XML document full of your entirely custom tags, not the output of the XSLT processor. Which is pretty cool in itself but not worth the attack surface.
[–] Telemakhos 3 days ago
Consider an API that returns not JSON but XML: a human viewing that data in a web browser would see a web page depicting the data, while a script fetching that data would get the underlying data as an intelligible and manipulable structure for further operations. The example usually given was a CD tracklist: a human would get a readable list, while a script would get data about titles, artists, etc, and could file that in a music library or perform other operations on it. I worked with TEI: a human could read a book encoded as TEI and transformed by XSLT into a web page that reproduced the text of the book, but a CMS collecting texts into a corpus could pull bibliographic data from the XML and index the TEI file among others into a library. The main idea was that underlying data should be separated from its presentation, so that XML files would function as data models for different consumers, while XSLT transformed that data for human consumers, and automated consumers would operate on the underlying model. If you remember the late 90s and early 00s, separating data from presentation of data was a major goal, and XSLT did that.
[–] cowlevel 3 days ago
[–] qrios 3 days ago
[–] cowlevel 3 days ago
[–] qrios 3 days ago
But it was fun. One use case was a browsable work package documentation for a big public funded project. The browser native print function rendered the page in a different style with valid page breaks and numbers.
[–] MattPalmer1086 3 days ago
For what we needed it would really have been faster - both to develop and certainly to run - to just write some custom code. Some reports on not that much data would take minutes or even an hour to run using XSLT.
Could have extracted the data from the database and written it out in whatever format in about a second. I do not mourn the gradual decline of XSLT.
[–] eichin 3 days ago
(I suspect if you had a catalog of "ways your startup can choose badly" for that era, we hit a lot of them. My top 3 were "attempt to do server balancing with a day's worth of latency data, using a perl script that took more than 24 hours to run and sometimes failed entirely", "Having a 20 person IT department to manage an outlook server for a 100 person company", and "Offering a senior engineer a VP position with firing authority to fix the outlook problem" :-)
[–] ergonaught 3 days ago
Bummer, I guess.
[–] genxy 3 days ago
I know "chrome is their browser" but Google has no business unilaterally decided what the fucking web runs now. They are just a big fucking adriddled bully.
[–] youngtaff 3 days ago
Fundamental issue is the library is maintained by one person (from memory) and no-one at the big corps wants to step up
[–] xp84 3 days ago
I never learned the first thing about it, other than its name, so I'll admit ignorance.
[–] ergonaught 3 days ago
I can only assume we would go in a different direction, today, even if XSLT weren't "dying", but it really did fit our use case really well.
> massive corporate penetration
By this standard, every desktop should still ship with a copy of Internet Explorer 6. Most of what made it "special" compared to say, the contemporary Firefox 2.0, was its huge pile of special sauce used only in corporate settings. That stuff had massive corporate penetration as well, but we moved on because ActiveX in the browser wasn't worth the security cost of keeping it around.
If there are important legacy things sitting around corporate environments that literally require XSLT to function, they've had over a year of warning in which to sort it out -- port it to something else, or, pick some alternative browser, pin its version, and set it up with a proxy that can only access your weird XSLT sites. They'll be improving their own security posture with that move, as well!
Random corporations' failure to plan doesn't constitute a need for the rest of the world to continue to maintain obsolete technologies for free.