XSLT was one of the things that brought me to React indirectly over a decade ago. I wanted to runs something like apply-templates (components) and that got me looking at XHP. That was the inspiration for JSX which became popular via react. Ironically I don't even use jsx anymore now that javascript has caught up, and a lot of what react does was really appealing from the declarative side. Weirdly so many of the "experts" are pushing very non-declarative approaches to it now. I'd love if xslt could achieve its stated goals, but like the rest of xml it's too academic and ignores obvious practical requirements.
What I like best about XSLT is that it reminds me that someone thought this was a great idea. They went so far as to declare it as “the way” and everyone should use it everywhere. There were conferences, books, blogs, everything. Anyone who criticized it was harshly rebuked and criticized. It isn’t just XSLT. The highway of IT progress is littered with these. XML, XSLT, CORBA, JEE… It’s helpful to keep in mind that nothing has changed, the current ones just haven’t blown up yet.
We need a word for these snake-swallowing-its-tail indirect abstractions we keep building. I have problem X, so I solve with abstraction a. Then I have problem Y, so I build b on a. Then to solve Z I build c on b on a. Then we discover a problem that is actually just X again, but rather than use a to solve we build d on c on b on a to solve it.
I remember installing enterprise java beans to support my soap wsdl 16 years ago. Meanwhile shopify built a basic Rails app using http verbs and killed the product I was using.
Ever since I played around with xhtml/xslt ~15-20 years ago when I was a lot newer to programming, I've always had the sense that it was a great way to do things, and that most sites should be using it. The last few days I've been playing with it again, and... I feel even more like that's true.
Even in its neglected state, it's got tons of features. You know how when Hacker News is having server issues, it tends to still work when logged out? Well you can just always serve the logged out page so it's cached for everyone, and then in the xslt template you can do an include of the user's data (that's right, you can directly include and query other xml documents in xhtml/xslt), e.g. <xsl:variable name="myinfo" select="document('/app/users/myinfo')"/> or something, and set that URL to private cache or no-cache, and then in the parts where you need the page to be different for the logged in user, you can e.g. compare '$myinfo/user/@id' to '@authorId' of a comment to decide whether to show an edit/delete button, etc. You basically get graceful degradation by default if it can't fetch that myinfo document. XPath is like jq that's been built into the browser this whole time.
The same thing can be used for things like subreddit side bars that are common across many but not all pages. You can even do an xsl:copy-of and serve it as xhtml. No need to send the same data over and over with SSR. No need to do client side routing or have any frontend tooling. It's all built right into the browser. The code is concise (it's verbose in the sense that it's xml, but it's still declarative) and easy to read. You can have a clean separation between backend sending the data in an xml model that makes sense for the domain, and then frontend having templates to present it.
The downside is of course that it all runs before the html for your page is produced, so you can't use javascript inside of xsl (unless you run a separate xsl processor in javascript), and it's about the same as SSR in terms of how dynamic it is (i.e. not interactive after page load, though you can of course have javascript in the output html). That and there's no info out there about how to use it because no one uses it, so you have to be a little creative. But it's been quite fun to see how much I can milk out of client side static template rendering using a technology that browsers haven't even bothered to update past 1.0 from 1999.
The first time I encountered XSLT I thought it was the most ridiculous thing to ever have been invented. A programming language written in XML?
but damn, the things you can do with that thing in a tiny bit of code. It was doing expression filtering years before anyone else, including the likes of Haskell.
yes, the learning curve can be a problem initially but, once you grok it, it opens up a whole world of interesting possibilities. and i do think, once you have created your initial transforms, it is then much easier for non-tech folks to "see" how things work and make tweaks/changes without having to mess with "code".
Ad-hoc and framework JavScript rendering JSON into the DOM is the modern way, don't you know? There's a reason for this: JSON is easier to produce than XML in many server-side systems.
Maybe what's needed is an extension to XSLT/XPath to consume JSON and transform it to XML.
yes. back in the day i would tend to wrap my database api in xml first in a standardised way and then i could just use xslt to return json or other formats from the api depending on the mime types requested by client. this fits in nicely with fielding's REST principles. all those technologies (HTTP/REST, XML, XPath, XML Schema, XSLT) actually work very nicely together and allow you to build nice systems that are very flexible, easy to integrate with and easy to change, even though they can be hard to make fast. maybe "move fast, break things" was a bad idea? =)
yes, there's definitely a bandwidth overhead with xml compared to json. that was an important factor in the shift i suppose. but then we have things like graphql, which has pretty much erased all those gains. you can also do tricky things like using binary on the wire and transforming at the endpoints.
it would be nice to see if fundamental xml tech can be improved in a new hardware and software environment. afaik, there hasn't been much if any innovation in that space in recent times. would love to know if there has.
I wasn't mature enough to grasp xslt at the time (the match construct confused me, and trees everywhere wasn't natural yet), but while you talk about corba and jee I had a few moments in the recent years where I thought all the json/rest/microservices are hand knitted remote beans..
well yes. i agree re corba, j2ee etc. but i think there were a lot of very nice technologies around xml that enabled automatic discovery, interop, validation etc. and we have ditched them all because there was also a lot of unnecessarily complex baggage and tooling that came with the ecosystem around them.
i even thought SOAP was quite nice if you used the message oriented flavour instead of RPC flavour. REST was imo better and won out, but then nobody really does REST today and we seem to keep on re-inventing the wheel. am watching the htmx discourse with interest.
I was at IBM during peak SOAP. It was crazy how much business pushed for abstraction for abstractions sake in this domain. I'm really hoping htmx helps people get their heads on straight with REST. All these scores of devs have been writing `POST /item {"method":"replace","id":12}` or `POST /item {"method":"delete","id":12}` for decades now.
yeah. RPC masquerading as REST is what people do now.
if your web service had a truly RESTful design then all you would need to do is point something like postman (or a browser) at it and it would be able to automagically figure out the whole set of available resources and interactions instead of having to use all this crazy swagger/OpenAPI stuff. there's a whole cottage industry around this api stuff rn.
i guess this is what happens when you put "programmers" in charge of a hypermedia system. everything becomes an RPC and nothing is standardised.
My day job combines assembly and XSL (GPU dev work can be weird). I have a soft spot for XSL; but, at this point, the combination of Python 3's performance story (concurrency, threading, multiprocessing), ElementTree, and itertools... I just don't see it anymore. Especially since any new hire has Python experience due to the current ML summer. I've been porting all my XSL to Python, and I couldn't be happier.
I still find it hard to write transformations nicely in normal programming languages. I actually even used it to transform structured formats and always am quite happy (using [0]). Also generated spreadsheets and docs (actually via markdown and pandoc) just 2 days ago. xsltproc is for me the awk/sed of structured.
yeah, making XML/XSLT fast is definitely a hard problem. still in pretty wide use in enterprise systems where correctness and interop are bigger priorities. i did quite a lot of work with shipping api's recently and you would be surprised how many of them are still XML and even SOAP based.
i'm intrigued by the combination of Assembly and XSL - any pointers to what you use those for?
