And given Jon Udell has written about XSLT before[0], I'm sure this was an intentional decision. Not sure I understand it though.
IMHO the pattern to improve XSLT is to call out into more useful languages like javascript, which ofc somewhat defeats the point of using it, but it is a useful pattern to slowly move away from it, when encountering it in legacy projects.
> but it's not unlike how you have to change your thinking for functional programming generally
I'd write lisp any day of the week over XSLT. I don't think XSLT deserves a place alongside other functional languages because its bound so tightly to xml. Sure, one can argue it has its place when processing XML but I'd pick a general purpose language and process XML with that over XSLT every time.
XSLT was held back by licensing, its why everything supports 1.0 and barely anything supports 2.0. If 2.0 was released for free then everything would use 2.0.
https://www.npmjs.com/package/saxon-js https://github.com/Saxonica/Saxon-HE
for reference: I'm not talking about today, I'm talking about that point in time where (for example) .NET could have adopted XSLT 2.0 but chose not to.
That said, it is emphatically not true that XSLT 2+ was somehow license-restricted. I worked at a company that used XSLT 2.0 and XQuery for code generation back in 2006, and we used the free edition with Saxon with no issues - paid versions had some optimizations and features like static type checking which we simply didn't need.
For the most part, XSLT 1.0 was "good enough" for most cases when XML was still the primary interchange format, and later JSON took over so there was less incentive for framework providers to spend resources on keeping up-to-date with the standard. Especially since XSLT 2.0 was such a massive leap in many ways, including a different data model that made many existing XSLT 1.0 processors incompatible in ways that required a massive redesign.
And what specifically do you mean when you say everything has to be processed as a one liner? I’ve never used an XSLT processor where that was true.
That it is a fiercely declarative language makes it hard to integrate. Often developers are placed within an architecture that gives them limited options and only being able to use XSLT while trying to integrate other network calls or services is non-trivial and a complete headfuck sometimes, compared with more general purpose languages like python or javascript.
Hard to integrate in what way? XSLT is a language focused on several things that it’s very good at but it’s not intended to replace Python or be a general purpose language. Yet there are many common data related tasks where a messy and hard to maintain pile of imperative code can be replaced with a simple XSLT.
Not everyone gets to pick and choose how they use XSLT. Place I used to work, the services team used to have a sign:
> [X] Days since last custom report
They hated it and I can't blame them, making a series of soap calls, consuming the most degenerate api ever written and generating a document for the customer was a pain. Bear in mind this was an enterprisey "do everything system", oversold by sales and the services team had to use XSLT to bridge the gap between customer expectation and what the salesman sold them.
What they needed was a host for a general purpose language, what they got was XSLT.
I guess what I am saying is: I see your point. I am also saying ( as I dig in a little deeper ) that XLST would likely be helpful.
I’ve personally never written an application using XSLT, but I’ve researched it a bit. In my limited understanding, I believe XSLT was designed for transformations that happen on initial page load, or in a SSR context. For dynamic client interactions like the ones enabled by React, it wouldn’t suffice since it’s designed to recreate the entire document on every pass.
^ I could be very wrong about this, would love for someone more knowledgeable than me to chime in and correct me.
Somewhat ironically, the semantic web was initially supposed to be built on browsers making calls for XML data (the X in Ajax) to then be displayed via XSLT. This model failed to gain adoption mostly because, let's be honest, XSLT is just blooming hard.
Nor did the spec itself stop evolving. The problem is that the browsers have deprecated the technology before XSLT 2+ could be adopted.
I know it depends of the definition of "modern browser", but I'm fairly sure that MSIE and pre-chrome Edge had lost support for it at some point, since MSXML stopped being shipped with them.
I honestly don't know what the current state of the art is, but Firefox doesn't do native XSLT anymore afaik (yes, you can do it in JS, but it's an extra step).
SSAX is probably the best xml parser I have ever used.
Sadly it doesn't seem like they're using it anymore.
Nope, but they sure had to make 1/2 the content about "AI" (otherwise nobody would read it?).