Comment by taeric

The thing most people never got about XSLT is that it is really about production rules -- and production rules (e.g. the major path to "expert systems") are one of the most solidly rejected technologies in software engineering.

I didn't understand this until I spent a few years going down a rabbit hole asking questions like "why don't people like production rules?" In the case of templating people expect to make a template with a top-down organization that looks like the output, whereas XSLT really wants you build transformations from the bottom-up. On some level the bottom-up part is clear, particularly if you want to code-generate your rules (towards the end I was writing production rules that write production rules) but what is not clear is how the parts all fit together: you can't visually tell between an XSLT that builds the structure you want vs one that doesn't.

I think the most fun I ever had with XSLT was when I used an XSLT engine with user-defined procedures and had them create side effects, such as matching certain patterns in an XML document and making SQL inserts, though that was a long time ago when we were still using terrible XML parsing libraries.

I’m a big fan of XHTML (strictness is good) and feel like XSLT could be a great addition, but I hate the syntax. I’d love to build a Jinja to XSLT compiler one day.

I also have a simple playground for XSLT: https://xsltbin.ale.sh/

XSLT is not bad, but XML, unfortunately, is normally misused, so XSLT is tainted as it has to be a part of that misuse.

The true role of XML are grammar-based notations. These occur in two places: when a human gives data to a machine and when a machine produces data for a human. This is where XML is used despite its often mentioned shortcomings; for example, many notations to describe the user interface are based on XML. This is convenient, because user interfaces are created manually. (I am not mentioning text markup, it is well known.)

Yet XML was often used as a notation for machine-to-machine exchange. For example, the ONIX book description standard. Here data are moved between two computers, yet for some reason they have to form grammatically correct phrases according to a set of grammar rules. Computers do not need grammar. They do just fine with non-grammatical data, like a set of tables. It is way simpler for them; parsing or generating grammar, even explicit, is pure overhead for data exchange and is only necessary when data enters or leaves the computed pipeline.

So, to your examples: configuration in XML is actually fine, but IPC is not. Configuration is written by hand, IPC happens between machines. IPC specification, on the other hand, is also a good fit for XML.

That said, XML and thus XSLT has another flaw: it is way too verbose and has no good way to format it. Conciseness was an explicit no-goal but now we can say it was a mistake.

here on HN I dare to out myself as a DSSSL lover, the scheme based predecessor of xslt.

I still can't wrap my head around how the neat and clean dsssl syntax, a real programming language, was replaced by an xml notation for the same: for cuntional code and a framework. because semantically, that's what xslt is: a functional language with a framework, geared at transforming xml instances.

but that syntax... and of course a much inferior and more obscure language than scheme underneath dsssl.

It's been a long number of years, but XUL (Mozilla/Firefox's UI layer) combined with XSLT was an incredible stack to build entire applications.

I regularly work with APIs in shell that return XML and XSLT is a goddamn super power. I adore it.

XSLT was cool.

XML needs another syntax that isn't so verbose. Sort of like how OWL has XML, Manchester, Functional, and Turtle syntaxes for the same data structures.

XSLT needs a Turtle-style syntax.

XML in general (the data structure, not the syntax) needs a Turtle-style syntax.

> but languished where it shined, as a markup language with an amazing transformation capability in XSLT

I choose to look at this a little differently.

An XML application using XSLT is so much better (faster load times, faster to write, easier to make correct) than a JavaScript application with a JSON api, that XML is basically a secret weapon.

I only care enough that it stays in browsers, but otherwise I'd prefer nobody know about it because it means less competition on things that matter (faster load times, faster to write, fewer bugs, etc). And I've got a half-baked JavaScript-based "renderer" I can finish in case some Google VP asshat goes looking for things to delete...

XSLT is just not a good language. Every single attempt of making XML executables (and there were many) failed badly, always for this one good reason.

I've been in the opposite, where people will go through lengths to try and make it so that the defaultish dom layout makes things "fall into place" so that they had a very specific layout of elements. When a fairly simple set of elements with somewhat minimal styling would get what you wanted surprisingly easy. Provided you did a lot of up front calculation on your own.

Basically, my assertion used to be to draw out what you have in mind on grid paper. Then start creating the elements. I don't see how that flow could land you with the 100ish divs that you wind up with on something like a single blue sky post.

Is it a panacea? No. Of course not. Can a constraint language help? I think so.

I'll add that the flex layouts seem like an improvement over what used to be there. Even if I find it rather amusing that we seem to have settled back on tables for layout. :D (I suppose it is more like some of the layout managers from Java days, truthfully.)

But, fundamentally, the problem appears to be that the drop to symbolic text is just not something that everyone does the same way. As such, it is very easy to get into a lot of trouble with the number of cooks in the kitchen, as it were.

Not really? People impose the idea that they can make this work. Yet no sites looked good on the Nintendo DS browser, and people were largely ok with that. Few sites look genuinely good on phones. People are largely ok with that.

It's good when someone advocates for what they believe to be progress on the web platform, but it's not necessarily clear that this would be progress. And that line in particularly is amusing because we absolutely don't know what good syntax for templating looks like — that's why there's so many different options.

JSX is certainly the most popular because it's used in the most popular framework, but it has some very clear weaknesses. In particular, it has very clear semantics for a React-like, VDOM-based framework, but those semantics do not work as well for other kinds of framework.

For example, you mention control flow via ternaries/`.map`. This works great in React, where the entire template will be reevaluated every time any input changes. However, frameworks like SolidJS or Vue in Vapor mode work very differently, and typically evaluate JSX only once at component mount (or at least, as seldom as possible). To support these, these frameworks need to use either special components like `For`/`Show`, or directives like `v-if`.

There's also the issue of how to evaluate JSX. In theory, JSX is flexible, in that `<Cpt prop={expr} />` can be converted to any call of the form `h(Cpt, {prop: expr})`. Again, that's not true for SolidJS or Vapor mode Vue — in both of these frameworks, `expr` cannot be eagerly evaluated, so the traditional transforms just don't work. Both of these frameworks therefore have to include their own custom plugins for handling JSX correctly.

The author's suggestion to also use signals as a state mechanism suggests they're imagining something more along the lines of SolidJS. That's an odd choice (it's my personal go-to framework, but it's also very niche), but it also implies, as discussed, that JSX-in-the-browser wouldn't behave like JSX-in-React. From experience, that will cause problems! I've worked with React developers before who've really struggled to use SolidJS because of precisely this issue.

I'm laughing because it just hits so hard. Started playing some role playing with friends again recently and we were looking for a template for the character sheets. You know what they have? A PDF. That is their template. Why? Because they design things that way.

And it is funny, because I can already feel the ideas that would go into templating this symbolically. Characters have 6 and 20 numeric attributes. But, I can already guess most would consider it a fault to manually place either of those on the page. Yes, the sheet has a limitation on how big your name can be. No, you can't really avoid that.

JSX is what happens when you no longer have a design and a dev team. It is great at that, even. But if you have a workflow where a designer makes a template and sends it over to a dev, it no longer really helps. You are much better off making something that can pick at artifacts that are handed off.

Instead, we seem to be aiming for an idea that will have to replace learning of everyone involved.

What is good, then? Because I'm really not seeing it. Just peek at substack and bluesky to see how the templating ideas in web dev have turned out. (I'm assuming they are decent modern examples. If not, I'm game to see one.)