Comment by pornel
10 hours ago
XSLT is merely a glorified compression/decompression mechanism.
XSLT used as a "stylesheet" in browsers isn't dynamic, so it's like browsing static HTML pages, but expanding of on-the-wire data representation into repetitive HTML is done with XSLT's rules instead of just gzip/brotli (and it doesn't make much difference, because regular compression is really good at compressing the same things that XSLT is good at generating).
For XHTML the effect is almost identical to preprocessing the data server-side, except minor quibbles about whose CPU time is spent on it, how many bytes can be saved.
The only remaining use-case for XSLT is stopping browsers from displaying RSS like garbage, but that's using one browser feature to fix another browser regression. It'd be easier and more helpful to bring back integrated RSS readers, instead giving you very sophisticated technology for apologising how useless the RSS URL is.
No, I don't think that's the right way to characterize it - it's not compression, it's separation of concerns. The original concept for XSLT was to separate the data from the presentation - and many successful systems were built using that technology. Some rendered server-side, some rendered in the browser.
A lot of publishers use XML formats like JATS [1] for articles and other documents. Those are rendered to HTML server-side using XSLT 2/3 and shown to users.
[1] https://jats.nlm.nih.gov/ ("Journal Article Tag Suite")