Hacker News Reader

Comment by speedgoose | Hacker News Reader

On a similar topic related to the display CSS property, you can attach a CSS to any XML document and have it displayed in a web-browser.

  <?xml-stylesheet type="text/css" href="style.css"?>

Bonus points if you mix that with XSLT.

View on HN

A site I worked in more than a decade ago now had all the HTML generated by applying XSLT to the API output.

An argument determined if you wanted the page as XML, html or RSS. If you opted for XML, and your browser supported XSL, the XSL would be applied client-side. We still applied the XSL server-side by default to avoid having to deal with compatibility issues for the XSL, but it worked perfectly in most browsers and was great for testing.

XSLT was/is a massive pain, though.

I store my resume in XML and use XSLT to generate an html version and Python to generate a plain text version. I made it about 10 years ago after I learned XSLT for a project at work. I feel secure in knowing that the XSLT code I wrote will never become obsolete, as compared to the Python script I wrote which will eventually become harder to run as Python 2 is phased out. The biggest disadvantage is that I haven’t done any XSLT work in 10 years so I need to relearn it every time the script needs modification.

It seems that the XSLT code you have written has become a different kind of obsolete

Not exactly what you meant, because here the css is included after XSLT is applied to XML: http://xsubs.tv/ice/seriesn%E2%84%96.xml

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.

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.

We do this for CCDA documents. Makes it easy when you're passing them around during development.

Reply on news.ycombinator.com