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.
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)?
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?
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.
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.
