12 ms·

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 wo

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 :/.

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 :/.