What's the whole point of bending over backwards to be "JavaScript-free" when the chosen alternative is using something as half-assedly hamstrung and counterintuitively crippled and mind-bogglingly rube-goldbergesque as XSLT, that tries to be all things to all people, thus satisfying no-one?

My impression of XSLT's design is that there were partisan representatives from every popular programming language paradigm on the XSLT standard committee, and each one of them was able to get just enough to showcase what was special about their own paradigm into the standard, while strategically sabotaging all the other competing paradigms to undermine and beclown each other, but not enough for practical coherency, or lord forbid neatly dovetailing together into a synergistic design.

When the Lisp faction evals and applies their functional paradigm, the BASIC faction runs to goto their imperative paradigm, and the Prolog faction is horny and unified that its logical paradigm makes the cut, the result is dysfunctional emparitive illogical programming.

Jeff Atwood points out that "Martin Fowler hates XSLT too":

https://blog.codinghorror.com/martin-fowler-hates-xslt-too/

I have no problem with XML. It’s a fine way to store hierarchical data in a relatively simple, mostly human-readable format. But I’ve always disliked its companion technology, XSLT. While useful in theory – “using a simple XSLT transform, XML can be converted into anything!”– in practice, it takes painful contortions to do anything practical. Evidently I’m not alone; Martin Fowler hates XSLT too:

>All of this site is written in simple XML documents and transformed to HTML. I find this works really well, and means I never have to worry about dealing with HTML formats. (Not that fancy layout is my style, as you can tell.) I’ve even written a whole book that way.

>For most of this time I’ve used XSLT as my transformation language. I’ve got pretty good with slinging XSLT around and getting it to do what I want.

>But no more.

>When I wrote the software for this Bliki (on a long flight) I did it in Ruby. Prior to that I used Ruby to do a new version of my home page. My conclusion from this exercise was that using Ruby for XML transforms was much easier than using XSLT.

I’ve had almost the same exact argument with a few developers I used to work with. After working through a bit of the XSLT necessary to accomplish something, I concluded that it was easier and simpler to use procedural code to do the same thing. Not always, of course, but most of the time. As Fowler points out, this does beg the question: what good is XSLT?

I think this may raise some real questions about XSLT. There’s still much I like about the power of XSLT, but I hate the syntax and the walls you keep running into. I’m not going to convert my whole site over to Ruby tomorrow – most of the XSLT works fine - but I can certainly see my way to doing that at some point in the future. But the bigger question is whether you’re better off with scripting language for this kind of task than XSLT.

Maybe the idea of XSLT transforming XML into “anything” is fundamentally unrealistic – just more Write Once, Run Anywhere snake oil.

I worked with XSLT a lot and I like it, but agree that a general-purpose programming language, preferably procedural, is more convenient and more powerful.

The reason XSLT is this way may be similar to why SQL is this way. SQL is declarative primarily because it isolates the user from concurrency. It would be much easier to write a procedure to fetch the data the way you want, but to write a concurrent procedure that does this safely and nicely among other such procedures would be much harder. XSLT was meant to be used with XML documents of unknown quality, so the logic of what is going on should be traceable. And XSLT did this rather well, given the constraints.

Upd: The constraints, as I see them, were that: the code will be written mostly by non-professionals (there were no professionals yet) so it should not be easy for them to get into an endless loop or otherwise shoot themselves in the foot. CSS faced similar constraints and was always rather awkward; nowadays it is also too complex and is only a formatting engine, not a transformation engine.

E.g. if XSLT was the main engine of the web CSS stylesheets would be unnecessary. The attributes could be placed on the elements themselves as this happens in XSL-FO. This would remove a major source of complexity; look at Tailwind, how popular it is, and why? Exactly because it removes an indirection step and instead of providing an external formatting rule merely formats an element directly.