←back to thread

XSLT – Native, zero-config build system for the Web

(github.com)
392 points _kush | 1 comments | 27 Jun 25 05:00 UTC | HN request time: 0.245s | source
Show context
CiaranMcNulty ◴[27 Jun 25 06:41 UTC] No.44394259[source]▶
It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats.

I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like `<xsl:include href="mycorp://invoice/1234">`

This may be out-of-date bias but I'm still a little uneasy letting the browser do the locally, just because it used to be a minefield of incompatibility

replies(8): >>44394503 #>>44394794 #>>44395004 #>>44395249 #>>44395303 #>>44396380 #>>44398418 #>>44399777 #
rwmj ◴[27 Jun 25 08:40 UTC] No.44395004[source]▶
XML is fine. A bit wordy, but I appreciate its precision and expressiveness compared to YAML.

XPath is kind of fine. It's hard to remember all the syntax but I can usually get there with a bit of experimentation.

XSLT is absolutely insane nonsense and needs to die in a fire.

replies(2): >>44395967 #>>44397069 #
1. cturner ◴[27 Jun 25 11:38 UTC] No.44395967[source]▶
It depends what you use it for. I worked on a interbank messaging platform that normalised everything into a series of standard xml formats, and then used xslt for representing data to the client. Common use case - we could rerender data to what a receiver’s risk system were expecting in config (not compiled code). You could have people trained in xslt doing that, they did not need to be more experienced developers. Fixes were fast. It was good for this. Another time i worked on a production pipeline for a publisher of education books. Again, data stored in normalised xml. Xslt is well suited to mangling in that scenario.