xslt is a native template system that has includes: <xsl:copy-of select="document('/header.html')"/>
xhtml/xslt still works today (though browsers are stuck on v1). It's a declarative template system with a pretty powerful pattern matching system (xpath). You can also extract fragments from external documents or store them into variables. e.g. <xsl:copy-of select="document('/content.html')/body/div[2]/ul/li/a/@href"/> will copy all urls from a list inside the 2nd div. Or instead of second div in the body, you could search for a div with an id or specific attributes or specific children or whatever pattern you want.
Why webdevs forsook xml will always be a mystery to me. Particularly given that they now use things like JSX.
I can only speak for myself, but the few times I encountered xslt in the past it was in the context of bulky and verbose SOAP services. The syntax felt off to me (and still do).
I think this was at the time I was learning jquery and using css selector syntax for finding elements, and the difference between that and xpath was pretty stark.
I basically (probably with insufficient knowledge) filed xslt away with vb and tables for formatting as old, complex and soon to be replaced
The syntax felt off to Juniper, too, so they made their own: https://juniper.github.io/libslax/slax-manual.html. Loses homoiconicity to some extent, sure, but outputting XSLT using XSLT never was particularly pleasant.
I just recently moved my personal homepage to XML + XSLT. Not a pro at it at all though. I did enjoy the process, I like the idea of building the website out of data + templates, but that's not unique to XSLT.
Besides some papercuts / browser bugs like "refreshing the page desyncs the inspector", the main issue I find with it is I don't see how I can modify things dynamically?
By the time JS runs, it's on the resulting HTML DOM, not the XML source, so I can't add elements dynamically respecting the XSLT stylesheet?
Also, XML must be well-formed and have a single root, I can't stream it out on the server piecewise?
With those 2 limitations, I don't see any advantages over any other server-side templating language, it just duplicates work that could happen once in a SSG or at least cached in a CDN, onto every client computer.
Right, unless you run a javascript xslt processor, you can't do things after page load. There's at least one javascript implementation that lets you do data binding to do dynamic page updates, but I'm not familiar with it.
The main advantage for simple things is that you don't need an application server or compiler. It's all static files, and it's all built right into the browser so easy to get started with. For less simple things, it should be easier to cache since you can separate out user data and have the bulk of the information you send be the static template (which the user can cache).
I suppose maybe that last point is why people use javascript frameworks for static pages (so they can send a static, cached js file and then small payloads for user data), which seems like overkill to me.
It would be nice if browsers supported streaming xml. Of course streaming xml exists (e.g. XMPP). It's not really any different than json: the spec said you need to have a single root object, and then someone wrote a spec that says you don't need to do that.
xhtml/xslt still works today (though browsers are stuck on v1). It's a declarative template system with a pretty powerful pattern matching system (xpath). You can also extract fragments from external documents or store them into variables. e.g. <xsl:copy-of select="document('/content.html')/body/div[2]/ul/li/a/@href"/> will copy all urls from a list inside the 2nd div. Or instead of second div in the body, you could search for a div with an id or specific attributes or specific children or whatever pattern you want.
Why webdevs forsook xml will always be a mystery to me. Particularly given that they now use things like JSX.