4 ms·

When I was young, naive, and still in HS, I thought XSLT would be the future. Imagine, one XML file, many representations! It could be your Database, your Websi

When I was young, naive, and still in HS, I thought XSLT would be the future. Imagine, one XML file, many representations! It could be your Database, your Website, everything! Writing one took forever, but never until I learned programming in university was I so amazed how some code had such a visible result.

vidarh 3y ago
I once built an entire site where the frontend was XSLT applied to XML from the middleware that spoke to the various data sources. You could set a url parameter and switch off the server side transformation to let the browser do it client side (and another to transform it into RSS instead of HTML). I liked the overall approach of a declarative transformation, but XSLT is absolutely awful and the lack of an alternative that's supported by browser made me not do it again.
- sam_lowry_ 3y ago
  Until very recently https://ted.europa.eu/ https://ted.europa.eu/ was build this way. It's probably still like that in the backend. I was always amazed how worked. What an underappreciated feat!
  - vidarh 3y ago
    The big challenge with XSLT was that the basics were verbose but easy - just pulling fields from the xml and putting them into a template. But then you ran into things that's simple with other solutions, like re-formatting dates and ended up with either humongous functions or biting the bullet and including multiple pre-formatted versions in the XML, and the moment you start down either of those paths you start to dislike XSLT pretty quickly. In a way modern React etc. frontends can be seen as a "fix", in the sense that at least it means most sites effectively have APIs, whether or not they officially expose them to users, but without the pain of XSLT. If they support server side rendering as well, they're getting close to what we were doing. And that was the original driver for the site design I mentioned - every URL was an API endpoint with a well defined set of expectations, letting you effectively explore the API by browsing the site as normal until you had sliced and diced the data the way you wanted and then just add a parameter to get it in the format you wanted (just as you can with Reddit - e.g. append ".json" or ".rss"). And I try to do that as much as possible still.
    - lmm 3y ago
      Yep. I built my blog to serve the markdown over HTTP and have a minimal stub to make the browser render it nicely. But that turned out to be much cleaner to do with Javascript than with XSLT. HN hates it, but I really think it's the way forward.
      - vidarh 3y ago
        I think HN would look at lot more favourable on it if it defaulted to do serverside rendering, but you could turn it off. I had a look, and for me at least on the initial load there's also a flash as the markdown displays and then gets replaced with rendered content, which kinda drives home that something unusual happens - it might also make it feel nicer to hide the markdown with css until it's rendered. (It's odd because it doesn't seem to happen consistently, even with a hard refresh.) Before the "XSLT adventure" I wrote a big webapp in C++, and we actually had a C++ rendering pipeline that had a component model to render not all that different to an initial React server-side rendering, combined with a pipeline where custom tags could be registered to further rewrite the output. I really liked that apart from being C++ and lacking the ability to optionally to client-side rendering.
        lmm 3y ago
        > had a look, and for me at least on the initial load there's also a flash as the markdown displays and then gets replaced with rendered content, which kinda drives home that something unusual happens - it might also make it feel nicer to hide the markdown with css until it's rendered. (It's odd because it doesn't seem to happen consistently, even with a hard refresh.) It's because the browser renders the <xmp> content itself first. I used to have that set to display:none which prevented the flash, but HN complained about not being able to see anything with Javascript turned off :/.
- rambambram 3y ago
  Oh man, you bring back memories. It had so many appealing features, but trying to do all kinds of logic with XPath et cetera became annoying very quickly.
Cthulhu_ 3y ago
I just miss a lot of tooling and standards from XML that JSON never got, or if they did, it wasn't as... correct?
hk1337 3y ago
Symphony CMS took that to heart. https://www.getsymphony.com https://www.getsymphony.com Not to be confused with Symfony framework. EDIT https://github.com/symphonycms/symphonycms https://github.com/symphonycms/symphonycms
marcosdumay 3y ago
Yeah, I was quickly dissuaded from that the first time I tried to write a XSLT. The same way that DTDs are very easy to work with... until you get a complex one created by a lot of people. XML is so incredibly full of horrible decisions that it's not funny. And they are never on the macro level of "this format is useless", they are always in the details.
giantrobot 3y ago
While XSLT is far from perfect, what I always loved was it was built into the browser. People have spent/wasted twenty years rebuilding templating systems in JavaScript. Browsers have had it all along but because it's related to XML it seems web devs' brains just seize up thinking that's only used by boring old Enterprise development. To be more charitable I think the problem has always been tooling. There's not a lot of good design tools that have supported XSL stylesheets as output. You've always had to do a lot of manual editing to get make a decent stylesheet and do any complicated functions. What's annoying is XSL can be used for any XML documents like you said. Your "pages" could just be serialized database entries with a stylesheet on them. Since all the styling was done client side the server is really just an API server. This was a design conceit of ATOM. It was mostly used for syndication but it was meant to be an XML API interface. It supported posting to a server in the ATOM XML definition as well as pulling. The idea being you'd come across a server with an ATOM API and be able to post comments or whatever to it right from a browser, no HTML form or JavaScript required.
starkparker 3y ago
XSLTs still get use in technical writing for DITA XML users. cf. https://www.oasis-open.org/committees/download.php/62943/2018_DITA-Adoption_BriefIntroToXSL_DRAFT.pdf https://www.oasis-open.org/committees/download.php/62943/201... (which is, of course, a PDF)

vidarh 3y ago

I once built an entire site where the frontend was XSLT applied to XML from the middleware that spoke to the various data sources. You could set a url parameter and switch off the server side transformation to let the browser do it client side (and another to transform it into RSS instead of HTML). I liked the overall approach of a declarative transformation, but XSLT is absolutely awful and the lack of an alternative that's supported by browser made me not do it again.

sam_lowry_ 3y ago
Until very recently https://ted.europa.eu/ https://ted.europa.eu/ was build this way. It's probably still like that in the backend. I was always amazed how worked. What an underappreciated feat!
- vidarh 3y ago
  The big challenge with XSLT was that the basics were verbose but easy - just pulling fields from the xml and putting them into a template. But then you ran into things that's simple with other solutions, like re-formatting dates and ended up with either humongous functions or biting the bullet and including multiple pre-formatted versions in the XML, and the moment you start down either of those paths you start to dislike XSLT pretty quickly. In a way modern React etc. frontends can be seen as a "fix", in the sense that at least it means most sites effectively have APIs, whether or not they officially expose them to users, but without the pain of XSLT. If they support server side rendering as well, they're getting close to what we were doing. And that was the original driver for the site design I mentioned - every URL was an API endpoint with a well defined set of expectations, letting you effectively explore the API by browsing the site as normal until you had sliced and diced the data the way you wanted and then just add a parameter to get it in the format you wanted (just as you can with Reddit - e.g. append ".json" or ".rss"). And I try to do that as much as possible still.
  - lmm 3y ago
    Yep. I built my blog to serve the markdown over HTTP and have a minimal stub to make the browser render it nicely. But that turned out to be much cleaner to do with Javascript than with XSLT. HN hates it, but I really think it's the way forward.
    - vidarh 3y ago
      I think HN would look at lot more favourable on it if it defaulted to do serverside rendering, but you could turn it off. I had a look, and for me at least on the initial load there's also a flash as the markdown displays and then gets replaced with rendered content, which kinda drives home that something unusual happens - it might also make it feel nicer to hide the markdown with css until it's rendered. (It's odd because it doesn't seem to happen consistently, even with a hard refresh.) Before the "XSLT adventure" I wrote a big webapp in C++, and we actually had a C++ rendering pipeline that had a component model to render not all that different to an initial React server-side rendering, combined with a pipeline where custom tags could be registered to further rewrite the output. I really liked that apart from being C++ and lacking the ability to optionally to client-side rendering.
      - lmm 3y ago
        > had a look, and for me at least on the initial load there's also a flash as the markdown displays and then gets replaced with rendered content, which kinda drives home that something unusual happens - it might also make it feel nicer to hide the markdown with css until it's rendered. (It's odd because it doesn't seem to happen consistently, even with a hard refresh.) It's because the browser renders the <xmp> content itself first. I used to have that set to display:none which prevented the flash, but HN complained about not being able to see anything with Javascript turned off :/.
rambambram 3y ago
Oh man, you bring back memories. It had so many appealing features, but trying to do all kinds of logic with XPath et cetera became annoying very quickly.

Cthulhu_ 3y ago

I just miss a lot of tooling and standards from XML that JSON never got, or if they did, it wasn't as... correct?

hk1337 3y ago

Symphony CMS took that to heart. https://www.getsymphony.com https://www.getsymphony.com Not to be confused with Symfony framework. EDIT https://github.com/symphonycms/symphonycms https://github.com/symphonycms/symphonycms

marcosdumay 3y ago

Yeah, I was quickly dissuaded from that the first time I tried to write a XSLT. The same way that DTDs are very easy to work with... until you get a complex one created by a lot of people. XML is so incredibly full of horrible decisions that it's not funny. And they are never on the macro level of "this format is useless", they are always in the details.

giantrobot 3y ago

While XSLT is far from perfect, what I always loved was it was built into the browser. People have spent/wasted twenty years rebuilding templating systems in JavaScript. Browsers have had it all along but because it's related to XML it seems web devs' brains just seize up thinking that's only used by boring old Enterprise development. To be more charitable I think the problem has always been tooling. There's not a lot of good design tools that have supported XSL stylesheets as output. You've always had to do a lot of manual editing to get make a decent stylesheet and do any complicated functions. What's annoying is XSL can be used for any XML documents like you said. Your "pages" could just be serialized database entries with a stylesheet on them. Since all the styling was done client side the server is really just an API server. This was a design conceit of ATOM. It was mostly used for syndication but it was meant to be an XML API interface. It supported posting to a server in the ATOM XML definition as well as pulling. The idea being you'd come across a server with an ATOM API and be able to post comments or whatever to it right from a browser, no HTML form or JavaScript required.

starkparker 3y ago

XSLTs still get use in technical writing for DITA XML users. cf. https://www.oasis-open.org/committees/download.php/62943/2018_DITA-Adoption_BriefIntroToXSL_DRAFT.pdf https://www.oasis-open.org/committees/download.php/62943/201... (which is, of course, a PDF)