Hacker News Reader

Comment by habitue | Hacker News Reader

This is a really cool hack.

> The JSON must contain only pure information without any concern about design or markup.

Wellll.. I mean the json has markdown syntax in it. That's a lot nicer than html tags for markup, but it's still markup.

In case anyone reading hasn't seen it before, browsers have a thing called XSLT built into them that does something similar for XML documents. You serve up your data as XML, add a tag that points to an XSLT document, and the browser will use the transform on your document automatically. If the resulting output is renderable XHTML, it'll display it like a regular webpage.

That being said, I wouldn't recommend doing that, since XSLT is a programming language whose syntax is XML itself. Apparently web standards folks in the early 2000s thought the future was XML all the way down.

View on HN

I still have nightmares from learning XSLT.

It's very cool, but also, very strange, if you come from a procedural language background.

Also, XSLT is really given power by being mixed with XPath (which is procedural).

I suspect that if I had known more about FP back when I learned it, I would have had an easier time. I wrote up a really long, painful post about XSLT, way back in the early 'oughts.

I learned XSLT twice. The first in the very early 2000s when I was creating a large and mostly static website for a magazine with a lot of content, and mostly just hacked it together. It was ok but mostly I was using it as a simple templating language. The second time was about five years ago, as a module in my MSc, by which time I was well-versed in functional programming — this time it was easy to do all sorts of weird and wonderful stuff, including a TAP-outputting assertion library for templates written in XSLT itself and a library for doing depth-first searches over graphs of nodes.

> XPath (which is procedural)

XPath is not procedural. It is entirely composed of expressions that compose and return results. The closest common language might be SQL.

Fair ‘nuff. I consider it “more proceduralish” than XSLT. It’s really more like an FP language.

XSLT is mainly used to transform XML into XML. The resulting document doesn’t have to be XML, though. I remember being assigned a task of parsing and importing a large XML document into a MySQL database. This was supposed to be done on PHP. I kind of felt repulsed by the idea of writing the parser in PHP (it would have been horrible). So, I used XSLT to transform the document into CSV and then just imported it using LOAD DATA. Worked like a charm.

In the beginning of my career, about 15 years ago, I had a job working with a large auto parts retailer and they had all of their products in these massive XML files. We used XSLT to transform those into all kinds of things, including physical printed catalogues that would go in their stores. Obviously the XSLT didn't actually print catalogues, but we did turn them into some format that I forget now (maybe PDF!) that we could just send straight to the printers.

It was pain and suffering developing these style sheets, but once done it worked like a charm.

> Obviously the XSLT didn't actually print catalogues, but we did turn them into some format that I forget now (maybe PDF!) that we could just send straight to the printers.

Was Adobe FrameMaker involved?

That must have been XSL-FO, a W3C standard. There are several implementations, like Apache FOP, that turn XSL-FO into PDF.

That's nice. I was in the same line of work. Started from building our own XML parser, when there were none available yet. Later I developed this fun XSLT that generated a fullblown Forms UI based on an XML and/or XML Schema which we used in a custom CMS. Then with XSL-FO and Quark XPress we generated user manuals and product catalogues from that. The XSLT was surprisingly fast for the time, and given the transformations it needed to do.

Later versions of XSLT added support for more high-level output formats - JSON etc.

One of the big problems with XSLT, is that XSLT only started to become useful after Version 2.0, and wasn’t supported by languages at that level. This was the main reason I stopped using it.

2.0 was (maybe still is?) supported by Saxon, a proprietary library, needing to be licensed. Built-in support was capped at 1.5.

If I remember, in order to run XSLT 2.0, you had to license and install Saxon on your server (i believe it was a Java application, meaning the server need to have a JVM), then call it, using system calls. Awkward, at best.

But this was many moons ago. I suspect/hope that things have improved, since then.

Saxon has an open source version that supports XSLT 3.0.

XQuery 3.1 has multiple open source implementations: Saxon, BaseX, xidel, and xqerl.

If you are coming from FP, XQuery is arguably a better fit. You lose template matching, but the syntax is much more concise (although still verbose by PL standards).

Yeah, I thought about using XML/XSLT too, but I think JSON would be more aligned with today's tools. Also, the render could be written in React or Vue, and add all the functionalities of a modern web app, for example, not just HTML.

Definitely your tooling is better incarnation of the idea, XSLT is kind of an abomination

Yeah, I don't have very fond memories about it.

I love XSLT in theory. It had the daring to say that the most frequently programmed thing that we do is just translate data structures of one shape into data structures of a slightly different shape, and it said “That is what I shall focus on, doing just that.” And the way that it produced that, by “just start writing your output document and insert XSLT when you finally need to loop or query the input” seemed quite nice too, a sort of PHP dialect which didn't have to “escape” out of the document type and resort to echoing raw text.

There is a pure functional programming language waiting to be resurrected from the ashes of XSLT, following Haskell's original idea that a program is a pure function from a stream of inputs to a stream of commands. I just hope that someone removes the XML from it, to save on the pain of my pinkies mashing those greater-than and less-than signs. I like the abstract idea that XML is recursively embeddable, and even the radical suggestion that maybe XSLT should be involved in metaprogramming its own syntax trees, but I am not sure that this is worth it. Maybe if we blur the lines between our code editor and a generic UI, someday?

Just setup a bijection between XML and s-expressions and XSLT becomes a Lisp.

The basic problem with XSLT is that it is strictly inferior to equipping any general-purpose programming language with an XPath implementation and just going to town. Let alone giving that programming language an even half-thought-out library designed to help with such a task.

Even Go, which is really not amenable to any sort of in-language DSL or syntactic sugar, is nicer to use than XSLT itself.

XSLT locks you in a trunk without enough tools to do what you need. I remember using a variant of XSLT Microsoft put out back in the day that let you embed Javascript into it... but then I noticed, why not just do it in Javascript? So I did. And it was soooo much better.

There are good ideas in XSLT, but they are so buried in a cascade of bad decisions and limitations and restictions and missing functionality and bizarre ways of doing things (and I mean, I speak Haskell, pure FP doesn't scare me, and they're still bizarre) that the best remedy is just to start over.

> There is a pure functional programming language waiting to be resurrected from the ashes of XSLT

That's XQuery. Version 3.1 handles JSON elegantly.

At NLnet, we use it as a static site generator.

https://stedolan.github.io/jq/

Pure functional programming language, where every expression is a generator. And it's installed on a ton of boxes already.

I'm quite fond of DataWeave for this, as an FP-inspired data transformation language with plenty of built-ins, including support for XML, JSON and beyond [0].

Apparently there's an online playground [1] and Beta support for LSP now [2]. I've only ever used it in a containerized-Java setting.

[0]: https://mjdresdner.medium.com/dataweave-2-x-playground-comin...

[1]: http://dwlang.fun/

[2]: https://github.com/mulesoft-labs/data-weave-language-server

It depends on which tools you're thinking about. When it comes to web browsers, they can process XML+XSLT (to produce and render HTML output) out of the box. On the other hand, it looks like the hack you're using here to make the JS renderer auto-load is not really valid HTML (as a whole)?

XSLT is the only way to do HTML templating on the client without using JS. I think that is valuable.

HTML templating with XSLT may be used to save data, too.

For example, if you build a social network profile page using XSLT, alice.xml and bob.xml can reference the same profile.xsl stylesheet which converts the XML profile data to the rendered HTML page. Since the profile.xsl stylesheet can be cached, whenever a new profile is visited, only the profile data in XML needs to be transferred.

Note that the templating can also be used to save data when rendering a single page. Imagine a Twitter clone that displays a list of tweets. If, hypothetically, 80 characters of Tweet data plus 500 characters of XSL template, produce 250 characters of HTML markup, you only need 3 tweets to start saving data (250x3=750 > 500+3x80=740).

XML+XSTL twitter clone in showHN in 3... 2... 1...

XML+XSLT is vastly, vastly underrated.

and vastly misunderstood.

Last time I was playing with these were IE6/7 times.

> Apparently web standards folks in the early 2000s thought the future was XML all the way down.

It should have been, but just like the masses rejected LISP for its parens, the masses rejected XML for the closing tag. We could have avoided PHP and the zoo of MVC frameworks.

We could have avoided the bedlam of javascript hacks if browsers had supported XSLT2.

I tried programming in XSLT and it was not fun. I'm sure if it took off we'd have the equivalent of Clojure that compiled down to it, but by itself it is not a hacker's language, if you know what I mean.

SXML and SXSLT did that in scheme and were really rather good fun.

If only XML wasn't so damn complicated, it might have had a chance. People love to point at close tags, but there's a long list of more serious problems.

External entities, namespaces within namespaces, CDATA, namespaces that confusingly look exactly like URLs, but aren't, parser vulnerabilities.

The way XML does namespaces is one of the best things about it - you can host any XML dialect within another, with no name clashes, and without losing the schema identity of embedded parts. Infinite data composability, subject only to the constraints placed by schema authors. And namespaces are URIs, so they can be URLs.

The bad smell was mostly coming from all the things inherited from SGML - CDATA, entities etc. Although I would also add that separation into elements and attributes is not a particularly convenient way to model many things; it mixes up differences that should really be orthogonal (ordered/unordered, atomic/composite etc).

I don't see why you even need the concept of namespaces to do that.

In my schema, I have a <foreignDocument> element, whose contents is defined to be a foreign document.

All of the things you mentioned serve a purpose that, at scale, would have to be replicated in some ad-hoc manner in JSON.

Yes XML is more expensive to parse, but so is all the extra stuff you have to do to get around the various limitations of JSON, which could have been done cheaply by an optimized XML parser.

> We could have avoided PHP and the zoo of MVC frameworks.

I doubt that. Javascript frameworks have their value inside a corporation - they enable replaceable cog worker programming. The result sucks, but hiring and replacing React programmers is easier.

Programming languages are addressed to humans, XML is addressed to machine. That is the difference. BTW the problem with lisp is not the parens, it is that it is too powerful for its own good. C++ and Java got there popularity from there restrictions really.

I had a college course that burned way too much time on XSLT. This was 2008 I think. Needless to say I haven't used it since

There is JSONT (https://goessner.net/articles/jsont/) and JSONPATH (https://goessner.net/articles/JsonPath/); also JUST (https://www.codeproject.com/Articles/1187172/JUST-JSON-Under...)

> browsers have a thing called XSLT built into them

I don't think they actually do anymore, not all of them for sure.

> web standards folks in the early 2000s thought the future was XML all the way down

Yes. What fools, to think that machine-produced content transmitted from machine to machine and displayed throw other machines would be better handled and more accessible if formatted in machine-friendly ways that were still readable to humans...

But it wasn't to be, not just because XSLT was somewhat botched (way too hard, way too many enterprise-looking warts...) and probably insecure, but because people are too lazy to produce readable markup (who wouldn't get tired of reading <prst><artdd><!CDATA[[ all day long...) and to make sure tags appear only where they should and get closed properly. Add the inevitable touch-of-death of enterprise vendors ("let's use xml in such a way you'll only be able to deal with it with our tools!"), and the game was up.

Working for a government agency that had bought into MarkLogic in 2004, we built an entire analytical site that used XML from the document server, queried via XPath, and rendered it into web pages via XSLT. The web page was defined entirely in the XSLT transform. Worked great and if you were already righting your data queries in XPath, writing the UI in XSLT kinda made sense.

> Wellll.. I mean the json has markdown syntax in it. That's a lot nicer than html tags for markup, but it's still markup.

Isn't markdown literally just HTML shortcuts for a limited set of common markup cases? IIRC, it's not uncommon to have to insert HTML tagging into markdown to get certain things to work.

Markdown compiles to html, and if I had to guess, it's probably a superset of html? (Maybe, possibly not all html is valid markdown, I haven't checked)

Assuming it's a superset though, the part I was talking about above was the (markdown - html) part, where markdown adds less noisy syntax for bolding, headings, lists etc.

I think Blizzard used to do this way back on their website.

There was a Web-based 3D community/game system that used browser-based XSLT. An employee of mine worked with it a lot.

I think it was called "Where," or "There," or something.

Way back when, the WoW armory (web-based character, guild, etc lookup) used to use this. It was incredibly useful for third-party integration - who needs scraping when they serve you the data on a silver platter.

Reply on news.ycombinator.com