Hacker News Reader

Comment by baybal2 | Hacker News Reader

On a similar topic, XSLT is still an excellent way to turn structured data into a page. It even works with RSS, ATOM, and OPML.

And you can even mix-and-match it with SPAs, and Vue.js with it's "hydration" system. That's an very power trick to slash data consumption, and improve cache hits for a "portal" style website. One showstopper: gazillion XSLT/XML bugs in Chrome left unfixed for 10+ years.

Another particularly interesting application is that you can turn XML data into SVG visualisation solely with XSLT, or you can add some JS with interactivity cod into XSL to run on the client side as a finishing step.

View on HN

I remember my college professor (back in 2007) betting his career that XSLT would become the defacto standard. It’s always a reminder to myself to not get blindsided by being stuck/locked into a single technology.

> XSLT is still an excellent way to turn structured data into a page

Is it, though? I would think its only real win over a template system based on a scripting language is when the template author is untrusted. And that niche is now much better covered by Liquid: https://shopify.github.io/liquid/

Tell me of a single template language supported client-side without JS

Maybe I just lack imagination, but what are the applications for this? The only thing I can think of might be some static data repository of raw XML files, which are accessed using a server that can send an XSLT header but you want to avoid loading up with template processing.

In the case of a webapp, you're running JavaScript anyway, so it doesn't really matter. Fun fact— very early Google Maps used XML for the ajax responses, and then switched to JSON for performance/simplicity reasons, since the result was being used in code anyway, not just rendered and displayed.

Traffic, and cache hit optimisation. By "hydrating" a transformed page you get the best of two worlds.

Both small initial package to render a page, cache hits, and relatively small SPA package.

XML API - robots exchange XML, converted to human form with a stylesheet, both on the fly and stored documents. From the description of fields to full blown application, think XSLX plugged Excel stylesheet.

That's how desktop applications work, maybe we should ask why is it not the norm? Why each request downloads application intertwined with data? Why can't one save response as one saves desktop document?

I am ok with JSON but I want a way to plug application supported by browser, XML is the only choice yet.

Arguably, the most characteristic feature of XSLT is that it uses XML for serializing code text itself. As such, one can expect most benefit from XSLT which uses lots of literal XML content embedded into XSLT. But that can be had with any general-purpose language having XML literals as well (such as JSX or old E4X). Other than that, XSLT still remains a competent markup processor, and XSLT 1.0 (but no later version) is indeed highly portable.

Since DSSSL (precursor of XSLT) is based on Scheme, I've always wondered if some HNers will pick-up OpenJade as its reference implementation.

You can compose multiple XML docs using XSL, the catch is XML is not rendering until the whole document is loaded in Chrome, the benefit on the other side is that XSL, and referenced XML docs are cacheable.

Reply on news.ycombinator.com