Oh, that would be something! All I want is to be able to make a website with some reusable elements and simple styling and keep adding content for decades, without having to think about keeping up with upgrades, dependencies and shifting framework paradigms.
I have made a couple of simple websites using PHP to bolt on reusable elements (header, footer, navigation), just because it is the solution that probably will work for ~decades without much churn. But XSLT would be even better!
The <template> element combined with the `cloneNode` works quite well for this. I've got a simple function which can take templates, clone them, fill in nodes with data from a structure, then prepare it to be added to the page.
Works a treat and makes most frameworks for the same seem completely pointless.
Includes are the feature of PHP that made it catch my eye many years ago. Suddenly not having to duplicate shared headers, footers, etc and keep it all up to date across my sites was magical. I could only barely write code at all back then but mixing PHP includes into otherwise plain HTML felt natural and intuitive.
I realize JS might not be to everyone's taste, but I think I've found the absolute minimal JS solution to reuse headers and footers: https://vladimirslepnev.me/write It's almost exactly like PHP but client side, there's no "flash of content" at all.
that's neat. i don't like inline js though. i'd like to be able to load it from a separate file so that i can reuse it on multiple pages.
i am thinking of something like
index.html
<div><navigation/></div>
index.js
function navigation() {
document.querySelector('navigation').replaceWith('<a href="...">...')
}
or maybe
let customnodes = {
navigation: '<a href="...">...',
...
}
then add a function that iterates over customnodes and makes the replacements. even better if i could just iterate over all defined functions. (there is a way, i just didn't take the time to look it up) then the functions could be:
function navigation() {
return '<a href="...">...'
}
and the iterator would wrap that function with the appropriate document.querySelector('navigation').replaceWith call.
That'll work but you'll get flash of content I think. (Or layout shift, idk what's the right name for it.) The way I did it, the common elements are defined in common.js and inserted in individual pages, but the insert point is an inline script calling a function, not a div with specific id. Then the scripts run during page load and the page shows correctly right away.
PHP is a bit more fragile than it used to be. It is probably a bit for the best but I've had to fix a lot of my 2010-era PHP code to work on PHP 8.x. Though... like, it wasn't super hard. The days you could just start using a variable passed in a URL without setting a default if it wasn't...
That would really be a surprising turn of events, and what a turn it would be! Imagine if the next generation of browsers supported XSLT 3.0—entire cabinets full of blog engines, static page generators, and much more could be rewritten. I support this. XSLT is one of those technologies that is too good to disappear. On the contrary, while some JavaScript frameworks have already turned to dust, I can still rely on my XML toolchains to work in 40 years' time.
3.0 adds JSON support, maps, arrays, to 2.0 - and many other other changes, including streaming and optimizable recursion with the oddly-named xsl:iterate, but the JSON support is biggest for the in-browser uses.
Ancient history for me but once upon a time my company was developing a web application with C++ that used XSLT to render HTML (with our "API" exposing data via XML). It was fast even then, and gave us a great deal of flexibility. We were certainly fans of XSLT.
It's a mistake to assume that the utility of a tool has anything to do with its adoption.
The real barrier to adoption for any tool are the network effects of other existing tools which create attention barriers and cultural barriers which may hinder adoption of superior alternatives.
A tool has to adhere and build on top of existing conceptual baggage in order to be appealing to the masses of developers.
This is partly because developers believe that the tools they're using now are cutting-edge and optimal... So a radical conceptual reinvention of their current favorite tools will look to them like a step backwards, regardless of how much further it can take them forward.
Isn't XSLT basically another programming language? Sure it's more limited than JavaScript and has some better built-in support for simple HTML templating, but it's still another full blown programming language. I wonder if we would see all the JS downsides in it if it became more widespread...
I read the Wikipedia on xslt, and as a long time web developer i do not understand at all how this would be useful. Plenty of people here are saying if this tech had taken hold we'd have a better world. Is there a clear example somewhere of why and how?
I think if you're of the belief that JavaScript is bad and should be avoided when possible this type of thing is seen as an alternative to that. But we've seemingly moved on to server side templating, or dynamic JavaScript apps which solve the problems that XSLT does in a more ergonomic and performant way. Compiling XML templates on the server or at build time is perfectly fine and doesn't require browser support. Doing it on the client leads to performance issues that we saw first hand with older SPA architectures, and if that isn't an issue, client side templating with JavaScript is more capable and ergonomic (imo).
It's a language that describes how to render a document.
For example, you could describe how to render your own domain specific markup language as HTML. Which is then happily viewed by the browser as a regular webpage, that can of course also be styled with CSS as usual.
This is only scratching the surface, really. But it does powerful transformations from one markup language to another.
This can of course be very useful as you get the browser able to present any markup without actually supporting said markup; without scripting or server side components.
It is just a special nostalgia for technologies which never became sucessful. They are percieved as more pure and perfect than the messy real world.
Client side XSLT transforms are very rarely useful. It was intended for a vision of the web as a multiude of different XML formats served to end users. Since this didnt happen (for good reasons), XSLT becase less useful. In reality it is only ever used to tranform into XHTML.
It was also touted as a more powerful style sheet since it could rearrange elements and transform semantic elements into tables for presentation. But CSS supports that now in a much better way, and most significantly CSS can react to dynamic updates.
Serving XML to end users only makes sense if someone actully understands the XML format. But only very few XML formats beside XHTML and SVG have any broad support. RSS is one of the few examples, and seem to be the main use case for XSLT.
XSLT is merely a glorified compression/decompression mechanism.
XSLT used as a "stylesheet" in browsers isn't dynamic, so it's like browsing static HTML pages, but expanding of on-the-wire data representation into repetitive HTML is done with XSLT's rules instead of just gzip/brotli (and it doesn't make much difference, because regular compression is really good at compressing the same things that XSLT is good at generating).
For XHTML the effect is almost identical to preprocessing the data server-side, except minor quibbles about whose CPU time is spent on it, how many bytes can be saved.
The only remaining use-case for XSLT is stopping browsers from displaying RSS like garbage, but that's using one browser feature to fix another browser regression. It'd be easier and more helpful to bring back integrated RSS readers, instead giving you very sophisticated technology for apologising how useless the RSS URL is.
No, I don't think that's the right way to characterize it - it's not compression, it's separation of concerns. The original concept for XSLT was to separate the data from the presentation - and many successful systems were built using that technology. Some rendered server-side, some rendered in the browser.
A lot of publishers use XML formats like JATS [1] for articles and other documents. Those are rendered to HTML server-side using XSLT 2/3 and shown to users.
Every mention of XSLT should mention XQuery. XQuery has roughly the same features as XSLT. They share the functions and data model. The syntax of XQuery is much nicer though.
XSLT/XQuery 3.0 versus 1.0 is a big upgrade. It includes JSON support and static type checking. At work, our webpage with thousands of pages is statically generated with XQuery 3.
XQuery has a different focus from XSLT. XQuery doesn’t have apply-templates, the document-based implicit dispatch that is so central to XSLT, and it doesn’t have the multiple inheritance possible with overloading templates, but it is stronger in the area of modules, and it assumes (in design) an index, a database.
Programmers tend to prefer XQuery syntax, but note that XPath 3 moves XSLT in that direction too, and XSLT 4 will take it further.
The main strength of XSLT for me is that, together with XML, it enables people who do not consider themselves programmers to do advanced text processing.
In the 90s I created a site with XSLT that rendered to HTML. I was tempted by its promises, but in practice I found it hard to use, hard to debug, complicated and extremely verbose. I was glad when I gave it up.
There is a fascinating alternative universe where XML standards actually took hold. I've seen it in bits and pieces. It would have been beautiful.
But that universe did not happen.
Lots of "modern" tooling works around the need. For example, in a world of Docker and Kubernetes, are those standards really that important?
I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Maybe it was the adoption of Python, whose JSON libraries are much nicer than XML. Maybe it was the fact that so few XML specs every became mainstream.
In terms of effort, there is a huge tail in XML, where you're trying to get things working, but getting little in return for that effort. XLST is supposed to be the glue that keeps it all together, but there is no "it" to keep together.
XML also does not play very nice with streaming technologies.
I suspect that eventually XML will make a comeback. Or maybe another SGML dialect. But that time is not now.
I think the simplest explanation is that developers used it and did not like it.
The pro-XML narrative always sounded like what you wrote, as far back as I can remember: The XML people would tell you it was beautiful and perfect and better than everything as long as everyone would just do everything perfectly right at every step. Then you got into the real world and it was frustrating to deal with on every level. The realities of real-world development meant that the picture-perfect XML universe we were promised wasn't practical.
I don't understand your comparison to containerization. That feels like apples and oragnes.
HTML was conceived as a language for marking up a document that was primarily text; XML took the tags and attributes from that and tried to turn it into a data serialization and exchange format. But it was never really well suited to that, and it's obvious from looking XML-RPC or SOAP payloads that there were fundamental gaps in the ability of XML to encode type and structure information inline:
I don't think this is the only factor, but I think XML had a lot of this kind of cognitive overhead built in, and that gave it a lot of friction when stacked up against JSON and later yaml... and when it came to communicating with a SPA, it was hard to compete with JS being able to natively eval the payload responses.
To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param, this is why we ended adopting openapi for describing http interactions and iirc jsonrpc specifically can also be described with it. At least in the schema part no one would say it is ambiguous, also one does not need do heavier parses, the obj is a tree, no more checking on scaping strings, no more issues with handcoded multiline strings, it is dropped the need to separate attributes with commas as we know the end tag delimits a space and so on.
> To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param
In practice, it doesn't matter.
If the JSON payload is in the wrong format the server rejects it with an error.
If the server sends an integer "by mistake" then the purists would argue that the client should come to a halt and throw up an error to the user. Meanwhile the JSON users would see an integer coming back for the id field and use it, delivering something that works with the server as it exists today. Like it or not, this is why JSON wins.
Schema defined protocols are very useful in some circumstances, but in my experience the added overhead of keeping them in sync everywhere and across developers is a lot of overhead for most simple tasks.
Putting the data into a simple JSON payload and sending it off gets the job done in most cases.
1) Work towards a more advanced system that addresses the issues (for example, RDF/Turtle – expands XML namespaces to define classes and properties, represents graphs instead of being limited to trees unlike XML and JSON)
2) Throw it away and start from scratch. First, JSON. Then, JSON schema. Jq introduces a kind of "JSONPath". JSONL says hi to XML stream readers. JSONC because comments in config files are useful. And many more primitives that existed around XML were eventually reimplemented.
Note how the discussion around removing XSLT 1 support similarly has two ways forward: yank it out or support XSLT 3.
I lean towards Turtle replacing XML over JSON, and for XSLT 3 to replace XSLT 1 support in the browsers.
> And many more primitives that existed around XML were eventually reimplemented.
Don't miss that they were reimplemented properly.
Even XML schemas, the one thing you'd think they were great at, ended up seeing several different implementation beyond the original DTD-based schema definitions and beyond XSD.
Some XML things were absolute tire fires that should have been reimplemented even earlier, like XML-DSIG, SAML, SOAP, WS-everything.
It's not surprising devs ended up not liking it, there are actual issues trying to apply XML outside of its strengths. As with networking and the eventual conceit of "smart endpoints, dumb pipes" over ESBs, not all data formats are better off being "smart". Oftentimes the complexity of the business logic is better off in the application layer where you can use a real programming language.
The simplest explanation is that attributes were a mistake. They add another layer to the structure and create confusion as to where data is best stored within it.
XML without attributes probably would have seen wide and ready adoption.
I agree. A sibling thread showed an example of XML above containing params/param/value/int/ nodes which with attributes could just be <param type=int>.
I do agree that attributes/data was always a huge contention point on where things should go and caused confusion and bikeshedding.
I also saw a bit of this in the React/JSX community with decisions like render props, HoC, etc where it took a bit to stabilize on best practices.
While i think a lot of xml was a bad idea, some of the issues are not instrinsically the fault of XML but some really poor design decisions by people making xml based languages.
They tended to be design by comittee messes that included every possible use case as an option.
Anyone who has ever had the misfortune of having to deal with SAML knows what i'm talking about. Its a billion line long specification, everyone only implements 10% of it, and its full of hidden gotchas that will screw up your security if you get them wrong. (Even worse, the underlying xml-signature spec is literally the worst way to do digital signatures possible. Its so bad you'd think someone was intentionally sabotaging it)
In theory this isn't xml's fault, but somehow XML seems to attract really bad spec designers.
Part of the problem was it came in an era before we really understood programming, as a collective. We didn't even really know how to encapsulate objects properly, and you saw it in poor database schema designs, bizarre object inheritance patterns, poorly organised APIs, even the inconsistent method param orders in PHP. It was everywhere. Developers weren't good at laying out even POCOs.
And those bizarre designs went straight into XML, properties often in attributes, nodes that should have been attributes, over nesting, etc.
And we blamed XML for the mess where often it was just inexperience in software design as an industry that was the real cause. But XML had too much flexibility compared to the simplicity of the later JSON, meaning it helped cause the problem. JSON 'solved' the problem by being simpler.
But then the flip side was that it was too strict and starting one in code was a tedious pita where you had to specify a schema even though it didn't exist or even matter most of the time.
The hard truth is that XML lost to the javascript-native format (JSON). Any JavaScript-native format would have won, because "the web" effectively became the world of JavaScript. XML was not js-friendly enough: the parsing infrastructure was largely based on C/C++/Java, and then you'd get back objects with verbose interfaces (again, a c++/java thing) rather than the simple, nested dictionaries that less-skilled "JS-first" developers felt at ease with.
It's a dumber format but that makes it a better lingua franca between all sorts of programming languages, not just Javascript, especially if you haven't locked in on a schema.
Once you have locked in on a schema and IDL-style tooling to autogenerate adapter classes/objects, then non-JSON interchange formats become viable (if not superior). But even in that world, I'd rather have something like gRPC over XML.
A dumber format works great for dumber protocols like RPC. When you're trying to represent something complex like a document, JSON is crap. Imagine the JSON equivalent of HTML. Then imagine editing it by hand.
"Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
> When you're trying to represent something complex like a document, JSON is crap.
I agree, but let's be honest, how often does this actually come up for data interchange. Because the situations where you want a human-editable document that is also computer-legible are fairly few in number. Prose in office documents, human-written documentation for code, config files.
For things where computer programs are driving the show (which is most the time, today), you want interchange designed for programming languages, whether that's JSON, CSV, gRPC, or what have you.
This even applies to documents that are completely computer-generated: get the inputs into an appropriate data structure using easy interchange formats, and then render to the output document (HTML, XML, LaTeX, etc.).
> Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
Fully agreed. But even where you do have documents, XML is not always the right thing either, which is why there are other markup formats in wide usage like TeX and Doxygen/Javadoc-style comments. XML seems best aligned to things like office document formats or other rich text where it makes sense to want to wrap some human text inside some computer-visible markers.
> how often does this actually come up for data interchange
Pretty much anywhere with text-heavy payloads? It's quite a lot, I think, but still dwarfed by the number of cases where system A needs to perform some sort of RPC-like communication with system B.
I just think that there is plenty of room in the world for both approaches.
I think the reason is that it solved the "problem" of integrating XML into JavaScript, as if being good at XML was an end in itself. Once XML started being replaced by JSON in earnest, what was the pressing need for E4X? Doing stuff in SOAP or WS-* presumably, but that wasn't a common use case in browser JavaScript, though it might have come in handy if Node.js took off a bit earlier.
JSX took off because it helped frontend developers solve problems outside of JSX. Look at examples of its use and it's heavily intertwined with the rest of what you'd see on a webpage (HTML, JS and CSS), and you never get the sense that JSX is a "self-licking ice cream cone".
This is the abstract idealism I was talking about: Every pro-XML person I've talked to wants to discuss XML in the context of a hypothetical perfect world of programming that does not exist, not the world we inhabit.
The few staunch XML supporters I worked with always wanted to divert blame to something else, refusing to acknowledge that maybe XML was the wrong tool for the job or even contributing to the problems.
Regarding containerization, XML wouldn’t just be a noun, but a verb (like in XSLT). You would define your remote procedures in XML.
Imagine if instead of the current Dockerfile format, we used XML, which was dynamically generated from lists of packages, and filtered and updates according to RSS feeds describing CSVs and package updates.
I’m not saying this is anything other than strange fantasy. And not a particularly nice fantasy either.
XML failed because it forced devs to spend tons of unproductive time on it
I think a key factor is: XML offers so many ways to serialize, you always have to decide in the individual case what the structure should be, what's an attribute, what's Text content, what's it's own attribute and those are important choices having impact on later changes.
With JSON you can dump data structures from about any language straight out and it's okay to start toying around and experimenting. Over time you might add logic for filtering out some fields, rename others, move stuff a little around without too much trouble.
Also quickly writing the structure up by hand works a lot faster in any editor, without having to repeat closing tags (while at some point closing brackets and braces will take their tribute)
However I agree: once you got the XML machinery, there is a lot of power in it.
I get your point but JSON still has a lot of the same problems; for example, no standard way to represent a timestamp. Despite being "javascript object notation" it's missing lot of javascript's types.
> I've seen it in bits and pieces. It would have been beautiful.
XHTML being based on XML tried to be a strict standard in a world where a non-strict standard existed and everybody became just very much aware on a daily that a non-strict standard is much easier to work with.
Seconded. I spend a whole lot of effort making my early 2000s websites emit compliant XHTML because it seemed like the right thing to do, and the way we were inevitably heading. And then I — and apparently almost everyone else, too, at the same time — realized it was a whole lot of busywork with almost nothing to show for it. The only thing XHTML ever added to the mix was a giant error message if you forget to write "<br/>" instead of "<br>".
Know what? Life's too short to lose time to remembering to close a self-closing tag.
About the time XHTML 1.1 came along, we collectively bailed and went to HTML5, and it was a breath of fresh air.
I don't understand this sentiment. Never have. I've doubted myself for years that I'm mistaken that this is how XHTML really fell out of favor despite it being what I recall reading at the time. A modern web developer is writing in javascript or typescript, which is going to make you correctly close your curly braces and parentheses (and so much more with typescript).
Then React introduced faux-XML as JSX except with this huge machinery of a runtime javascript virtual DOM instead of basic template expansion and everyone loves it? And if this react playground I've opened up reflects reality, JSX seems to literally require you to balance opening/closing your tags. The punch-line of the whole joke.
What was the point of this exercise? Why do people use JSX for e.g. blogs when HTML templating is built into the browser and they do nothing dynamic? For many years it's been hard to shake the feeling that it isn't some trick to justify 6 figure salaries for people making web pages that are simple enough that an 8 year old should be up to the task.
That same nagging feeling reassures me about our AI future though. Easy ways to do things have been here the whole time, yet here we are. I don't think companies are as focused on efficiency as they pretend. Clearly social aspects like empire building dominate.
It was pretty evident when it happened, particularly because XHTML in some browsers was parsed with a sloppy HTML parser, and in some with an XML parser which was strict. Guess what happened. Tons of invalid XHTML was out there and it made it impossible to parse as XML.
And some of the sloppy parsers rejected valid XML that the strict parsers accepted.
Combined with Firefox and MSIE having different combinations of HTTP headers and doctype declarations to specify XHTML mode, it was way too hard to emit one single doc that was viewable on all common browsers. For a while my life involved regularly chasing down random issues that suddenly made our customers' browsers show an error page instead of the content, even when it was actually valid and passed all validators.
> Why do people use JSX for e.g. blogs when HTML templating is built into the browser and they do nothing dynamic?
...but real HTML templating isn't built-in to HTML[1]. Its absence for these 30 years is as huge a mystery as why there's no combobox input element (combination textbox+drop-down) or <select>'s limitations.
[1] What I mean by this is that JS+DOM still has no simple way of escaping HTML in a string. It's insane.
To elaborate: if you have a some arbitrary strings (unsanitized user input): `headerText` and `firstParagraph` that you want to render to a HTML fragment like `<h2>{headerText}</h2><p>{firstParagraph}</p>` then the only real way of doing this safely is by using the (archaic and verbose) DOM Level 1 methods (document.createElement, textContent = 'text', etc) which somehow always turn what-should-be a 1-liner pure-function in any sane language to a 10-line function with side-effects (...and as it's 2025 then it will probably be async too).
When JS added support for template-literals, I was excited that this might mean an end to the embarrassing problem, but because it didn't ship with HTML-escaping it means it's useless for that purpose - unless you're going to go through the effort to implement a full "tagged template" with a parser function, which I assume would handle the DOM parts.
It could be that we have drastically different ideas of "easy way to do things". To me, XSLT has never remotely resembled an easy way to do things. It seemed like a weird, difficult, almost deliberately obtuse horse designed by committee that technically worked but in a horrifying kind of way, like finding that someone write a C compiler Bash. Wow, it's cool that someone was able to do it at all, but I can't imagine ever wanting to jump on that train.
The problem with XML is that it’s horrible to manually read and write, and it takes more effort to parse too. It’s a massive spec which contains footguns (a fair few CVEs exist just because of people using XML on publicly accessible endpoints).
Now I do think there is a need for the complexity supported by XML to exist, but 99% of the time JSON or similar is good enough while being easy to work with.
That all said, XHTML was amazing. I’d have loved to see XHTML become the standard for web markup. But alas that wasn’t to be.
I doubt this is really meaningful. It's not like browsers are forgiving about malformed javascript. We live with "tough, the developer screwed up" every day.
I think you're getting at a very often discussed ebb and flow between being extremely controlled vs extremely flexible. XML was astounding compared to system specific proprietary systems, and then as the need for formalism grew people wanted something simpler... And now you see the same thing growing with JSON and the need for more rigor. I personally think there are many forces to all of this, just the context at the time, prevailing senses of which things are chores and which aren't, companies trying to gain advantage, but probably most importantly is that the vast majority of people have a subset of historical information about systems and computer science, myself included, yet we have to get things done.
I legitimately tried my best to like XLST on the web back in the day.
The idea behind XLST is nice — creating a stylesheet to transform raw data into presentation. The practice of using it was terrible. It was ugly, it was verbose, it was painful, it had gotchas, it made it easier for scrapers, it bound your data to your presentation more, and so on.
Most of the time I needed to generate XML to later apply a XLST style sheet, the resulting XML document was mostly a one off with no associated spec and not a serious transport document. It begged the question of why I was doing this extra work.
Making your data easy to scrape is part of the point (or just more generally work with). If you're building your web presence, you want people to easily be able to find the data on your site (unless your goal is platform lockin).
The entire point of XSLT is to separate your data from its presentation. That's why it made it easy to scrape. You could return your data in a more natural domain model and transform it via a stylesheet to its presentation.
And in doing so it is incredibly concise (mostly because XPath is so powerful).
> I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Whoa, that doesn't have anything to do with the dislike for XML. We dislike XML because its use is heavily correlated with IBM java tech stack, and that is a complete disaster in usability and project management.
IBM WebSphere with all its fragile XML configuration files, which can't be edited by hand because everything breaks if you try, are my reason to avoid XML since, and if I ever have to choose, I will choose against XML.
Containerisation became a normal practice about a decade after I and the other developers I know, started to avoid XML.
> I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Not sure how that is true. XML is a specification for a data format, but you still need to define the schema (i.e., elements, attributes, their meaning). It's not like XML for web pages (XHTML?) could also serve as XML for Linux container descriptions or as XML for Android app manifests.
Yeah this 100%. JSON took off only partly because it has less tedious syntax. The other big reason is that its data model is actually what you really want 99% of the time. XML has to be squashed awkwardly into the normal object-based data model that most programming languages use.
I actually rather like XML(asterisk) But this is one of it's warts, It wants to be two things, A markup language, it's in the name and arguably where it should have stayed, and an object notation. This is where you start to question some of XML's fundamentals, stuff like why is it redundant? When do you stick data in attributes? Or is it better to nest tags all the way down?
Asterisk: except namespaces, I loathe those, you are skipping happily along chewing through your XML, xpathing left and right, and then find out some psychopath has decided to use namespaces, and now every thing has become super awkward and formal.
Namespaces are essential whenever you want to insert contents defined by one schema into “payload” or “application-defined” elements of another schema. There are also more complex scenarios where attributes from one schema are used to annotate elements from a different schema.
Well, I guess we could do it like libraries in C-land and have every schema add its own informal identifier prefix to avoid name collisions. But there’s a reason why programming languages moved to namespaces as an explicit notion.
>XML also does not play very nice with streaming technologies.
Not sure why just as good as JSON, if you are going to stream and parse you need a low level push or pull parser not a DOM just like JSON. See SAX for Java or XmlReader / XmlWriter in .Net.
XSLT 3 even had a streaming mode I believe which was badly needed but had constraints due to not having the whole document in memory at once.
I liked XSLT but there is no need for it, javascript is good enough if not better, many times you needed to do a xslt script tag to get some thing done it couldn't do on its own anyway, might as well use a full language with good libraries for handling XML instead. See Linq to XML etc.
Right, both sort of suck at streaming, something about being closed form tree structures would be my guess(strictly speaking, you need to close the tree to serialize it, so no clean way to append data in real time, best you can do is to leave the structure open and send fragments). Having said that, I am not really sure what a good native streaming format would look like. Best guess is something flatter, closer to CSV.
>Right, both sort of suck at streaming, something about being closed form tree structures would be my guess(strictly speaking, you need to close the tree to serialize it, so no clean way to append data in real time, best you can do is to leave the structure open and send fragments).
Again don't really agree, its just most developers don't seem to understand the difference between a DOM or parsing JSON into a full object vs using a streaming reader or writer so they need to be hand fed a format that forces it on them such as line based CSV.
Maybe if JSON and XML allowed top level multiple documents / objects it would have helped like JSON lines.
If XForms was released on browsers today, it would be hailed as a revolutionary technology. Instead, it is just one of the many things thrown away, and even now 20 years after the WHATWG took over we cannot even do a PUT request without Javascript.
> I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
It got abandoned because it sucks. New technology gets adopted because it's good. XML standard were just super meh and difficult to work with. There's really not much more to it than that.
The Semantic Web was never going to win. It does not make sense on a fundamental level.
XHTML's failure had nothing to do with it, and is basically unrelated. Even if xhtml won i fail to see how that would have helped semantic web in any way shape or form.
XML died because it sucks. Everyone who had to deal with it back in the day jumped to YAML and/or JSON as quickly as they could. Google didn't cause that, but because they're a search engine they followed it.
XSLT currently provides a lot of value, as the browser can use it to transform documents directly, and it is exposed to JavaScript for scripting. Exploring it recently, including creating a PWA with XML sources reminded me why I like developing on the web. It made me think--RSS feeds can be PWA's now--right?
It seems like XSLT 3.0 would open up a lot of new opportunities and patterns, especially if it continues to work with existing standards, as the current version does. The Web Platform is so cool.
Yes. That's the right solution for the even playground regarding the situation:
Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues" ).
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user !
Chrome clearly outcompeted Firefox despite Firefox’ faster XSLT implematation, so perhaps the performance of a feature which is almost never used is not that significant either way?
Chrome is outcompeting (or cripling) Firefox - in taking control from the user, payed by the user - right now, with your comment all backward (and catch 22, cross-browser functionality bugs never to be fixed).
All downvoted ? If not performance of [ONE] feature like JS engine, what would make Chrome better ? (crippling others). JS is used so much only because all other options are kept broken (since Microsoft JS XMLHttpRequest - for applications not documents, being the lowest common denominator - against few bugs that needed to be fixed, not much changed) - otherwise there will be no need of JS for documents processing and less energy wasted - and the bill is payed not by corporations but by users, with extra tracking taxes.
Chrome mostly can do anything Firefox can do since removing its "legacy extensions", so Firefox has to remove XSLT too - as Google can't afford it being not helpful for tracking - and can compete only with its JS engine - so XSLT, if to stay, could in the future only be reimplemented in JS polyfills no more, making it less useful, not cached, not transparent - to let Chrome 'outcompete' others again, race to the bottom, everything looks like a nail.
Hopefully that could be enough to complete the evidence to split Google into pieces in antitrust case - or realizing that will make Google to back off ?
yet making it to be interlinked code too.. may not last, as codes like changing and finding new ways.
Fancy stuff as JS may be very useful and I like it too, momentary, when well applied, but it needs: an effort to use it, keep working, adapting, if interoperating, all specific, for the purpose - and power, can't open 1000s tabs. Different kind of being. More fun, like with the hammer for everyhthing - not shy like XSLT trying be transparent.
If the P in SPA exists to load your app, then why care? If you’ve noticed the herd thin as SSE and hypermedia trim split ends, then you may see the utility in open web tooling.
Things like XML and XSLT were useful and nice when I used them in 2004. But that's more than 20 years ago now. It's not something I encounter regularly in modern tech stacks. How widely used is this stuff in browsers at this point? I don't think browsers should be burdened with a lot of complex solutions to serve a few minority/niche use cases.
And even then, using this stuff server side was more common than relying on browsers. XHTML was still being actively pushed and Whatwg kind of made that go away in favor of HTML5. Whatwg was a breadth of fresh air in the whole captial S and lower case s semantic web debates between XML purists on one hand and people just trying to create browsers that worked on the other hand. The latter camp won by virtue of eventually producing browsers that implemented Whatwg standards and then world+dog voting with their feet and making use of those browsers and standards. The whole debate just fizzled out after that.
XSL support in browsers is part of some of the reasons WhatWG was created: a lot of poorly thought through and half specified features being proposed by and rushed through the W3C. Which was putting browser makers on the spot having to support all that in a way that worked well across browsers. The job of "lets just sit down and specify this stuff properly" is why Whatwg was created. That's a job that took many years and it created the modern web and finally enabled high levels of interoperability between browsers.
And there are other mechanisms available to developers that are well endorsed by browser makers and standards. Including using whatever libraries you want in WASM form and running them in a sandboxed environment in a browser. Which is also complex of course but at least is being widely used and well specified at this point. I don't see many compelling reasons for this stuff to live outside of that sandbox.
Related ongoing thread:
Google did not unilaterally decide to kill XSLT - https://news.ycombinator.com/item?id=44987239
Recent and also related:
XSLT removal will break multiple government and regulatory sites - https://news.ycombinator.com/item?id=44987346 - Aug 2025 (99 comments)
"Remove mentions of XSLT from the html spec" - https://news.ycombinator.com/item?id=44952185 - Aug 2025 (523 comments)
Should we remove XSLT from the web platform? - https://news.ycombinator.com/item?id=44909599 - Aug 2025 (96 comments)
Oh, that would be something! All I want is to be able to make a website with some reusable elements and simple styling and keep adding content for decades, without having to think about keeping up with upgrades, dependencies and shifting framework paradigms.
I have made a couple of simple websites using PHP to bolt on reusable elements (header, footer, navigation), just because it is the solution that probably will work for ~decades without much churn. But XSLT would be even better!
The <template> element combined with the `cloneNode` works quite well for this. I've got a simple function which can take templates, clone them, fill in nodes with data from a structure, then prepare it to be added to the page.
Works a treat and makes most frameworks for the same seem completely pointless.
could you share some examples please? i am interested in trying this out.
Includes are the feature of PHP that made it catch my eye many years ago. Suddenly not having to duplicate shared headers, footers, etc and keep it all up to date across my sites was magical. I could only barely write code at all back then but mixing PHP includes into otherwise plain HTML felt natural and intuitive.
I realize JS might not be to everyone's taste, but I think I've found the absolute minimal JS solution to reuse headers and footers: https://vladimirslepnev.me/write It's almost exactly like PHP but client side, there's no "flash of content" at all.
that's neat. i don't like inline js though. i'd like to be able to load it from a separate file so that i can reuse it on multiple pages.
i am thinking of something like
index.html
index.js or maybe then add a function that iterates over customnodes and makes the replacements. even better if i could just iterate over all defined functions. (there is a way, i just didn't take the time to look it up) then the functions could be: and the iterator would wrap that function with the appropriate document.querySelector('navigation').replaceWith call.That'll work but you'll get flash of content I think. (Or layout shift, idk what's the right name for it.) The way I did it, the common elements are defined in common.js and inserted in individual pages, but the insert point is an inline script calling a function, not a div with specific id. Then the scripts run during page load and the page shows correctly right away.
As the article states, this is analogous to php echo. But this thread is about php include: how does it help there?
Edit: I see; you use it as a template further down. My bad for not reading through.
PHP is a bit more fragile than it used to be. It is probably a bit for the best but I've had to fix a lot of my 2010-era PHP code to work on PHP 8.x. Though... like, it wasn't super hard. The days you could just start using a variable passed in a URL without setting a default if it wasn't...
That would really be a surprising turn of events, and what a turn it would be! Imagine if the next generation of browsers supported XSLT 3.0—entire cabinets full of blog engines, static page generators, and much more could be rewritten. I support this. XSLT is one of those technologies that is too good to disappear. On the contrary, while some JavaScript frameworks have already turned to dust, I can still rely on my XML toolchains to work in 40 years' time.
As long as you only use 1.0.
Unless 3.0 fixes the reasons why 2.0 doesn't exist in the wide world, it'll just lead to more problems.
3.0 adds JSON support, maps, arrays, to 2.0 - and many other other changes, including streaming and optimizable recursion with the oddly-named xsl:iterate, but the JSON support is biggest for the in-browser uses.
4.0 will add parse-html() too.
Ancient history for me but once upon a time my company was developing a web application with C++ that used XSLT to render HTML (with our "API" exposing data via XML). It was fast even then, and gave us a great deal of flexibility. We were certainly fans of XSLT.
It's a mistake to assume that the utility of a tool has anything to do with its adoption.
The real barrier to adoption for any tool are the network effects of other existing tools which create attention barriers and cultural barriers which may hinder adoption of superior alternatives.
A tool has to adhere and build on top of existing conceptual baggage in order to be appealing to the masses of developers.
This is partly because developers believe that the tools they're using now are cutting-edge and optimal... So a radical conceptual reinvention of their current favorite tools will look to them like a step backwards, regardless of how much further it can take them forward.
Isn't XSLT basically another programming language? Sure it's more limited than JavaScript and has some better built-in support for simple HTML templating, but it's still another full blown programming language. I wonder if we would see all the JS downsides in it if it became more widespread...
I read the Wikipedia on xslt, and as a long time web developer i do not understand at all how this would be useful. Plenty of people here are saying if this tech had taken hold we'd have a better world. Is there a clear example somewhere of why and how?
I think if you're of the belief that JavaScript is bad and should be avoided when possible this type of thing is seen as an alternative to that. But we've seemingly moved on to server side templating, or dynamic JavaScript apps which solve the problems that XSLT does in a more ergonomic and performant way. Compiling XML templates on the server or at build time is perfectly fine and doesn't require browser support. Doing it on the client leads to performance issues that we saw first hand with older SPA architectures, and if that isn't an issue, client side templating with JavaScript is more capable and ergonomic (imo).
It's a language that describes how to render a document.
For example, you could describe how to render your own domain specific markup language as HTML. Which is then happily viewed by the browser as a regular webpage, that can of course also be styled with CSS as usual.
Or how to render Markdown as HTML without a Markdown generator (might require rarely implemented XSLT 2.0 with XPath 2.0). See: https://stackoverflow.com/questions/3549827/converting-simpl...
Or render HTML as some other markup language.
This is only scratching the surface, really. But it does powerful transformations from one markup language to another.
This can of course be very useful as you get the browser able to present any markup without actually supporting said markup; without scripting or server side components.
It is just a special nostalgia for technologies which never became sucessful. They are percieved as more pure and perfect than the messy real world.
Client side XSLT transforms are very rarely useful. It was intended for a vision of the web as a multiude of different XML formats served to end users. Since this didnt happen (for good reasons), XSLT becase less useful. In reality it is only ever used to tranform into XHTML.
It was also touted as a more powerful style sheet since it could rearrange elements and transform semantic elements into tables for presentation. But CSS supports that now in a much better way, and most significantly CSS can react to dynamic updates.
Serving XML to end users only makes sense if someone actully understands the XML format. But only very few XML formats beside XHTML and SVG have any broad support. RSS is one of the few examples, and seem to be the main use case for XSLT.
(now I see it, obviously, you does not seem to know what you are talking about - in any case, just.. can you live and let others live too ? Thx.)
XSLT is merely a glorified compression/decompression mechanism.
XSLT used as a "stylesheet" in browsers isn't dynamic, so it's like browsing static HTML pages, but expanding of on-the-wire data representation into repetitive HTML is done with XSLT's rules instead of just gzip/brotli (and it doesn't make much difference, because regular compression is really good at compressing the same things that XSLT is good at generating).
For XHTML the effect is almost identical to preprocessing the data server-side, except minor quibbles about whose CPU time is spent on it, how many bytes can be saved.
The only remaining use-case for XSLT is stopping browsers from displaying RSS like garbage, but that's using one browser feature to fix another browser regression. It'd be easier and more helpful to bring back integrated RSS readers, instead giving you very sophisticated technology for apologising how useless the RSS URL is.
No, I don't think that's the right way to characterize it - it's not compression, it's separation of concerns. The original concept for XSLT was to separate the data from the presentation - and many successful systems were built using that technology. Some rendered server-side, some rendered in the browser.
A lot of publishers use XML formats like JATS [1] for articles and other documents. Those are rendered to HTML server-side using XSLT 2/3 and shown to users.
[1] https://jats.nlm.nih.gov/ ("Journal Article Tag Suite")
This is neither correct nor helpful, i think. There are examples of dynamic pages using XSLT, and the purpose is not compression at all.
A very simple one - https://wendellpiez.github.io/XMLjellysandwich/IChing/
You might as well say JavaScript is just a compression format for Web assembly language.
Except, authors can directly write the "compressed" representation, which can be vastly more convenient. (Like in every templating system)
Every mention of XSLT should mention XQuery. XQuery has roughly the same features as XSLT. They share the functions and data model. The syntax of XQuery is much nicer though.
XSLT/XQuery 3.0 versus 1.0 is a big upgrade. It includes JSON support and static type checking. At work, our webpage with thousands of pages is statically generated with XQuery 3.
XQuery has a different focus from XSLT. XQuery doesn’t have apply-templates, the document-based implicit dispatch that is so central to XSLT, and it doesn’t have the multiple inheritance possible with overloading templates, but it is stronger in the area of modules, and it assumes (in design) an index, a database.
Programmers tend to prefer XQuery syntax, but note that XPath 3 moves XSLT in that direction too, and XSLT 4 will take it further.
The main strength of XSLT for me is that, together with XML, it enables people who do not consider themselves programmers to do advanced text processing.
In the 90s I created a site with XSLT that rendered to HTML. I was tempted by its promises, but in practice I found it hard to use, hard to debug, complicated and extremely verbose. I was glad when I gave it up.
These problems are a large part of why later versions of XSLT were developed.
There is a fascinating alternative universe where XML standards actually took hold. I've seen it in bits and pieces. It would have been beautiful.
But that universe did not happen.
Lots of "modern" tooling works around the need. For example, in a world of Docker and Kubernetes, are those standards really that important?
I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Maybe it was the adoption of Python, whose JSON libraries are much nicer than XML. Maybe it was the fact that so few XML specs every became mainstream.
In terms of effort, there is a huge tail in XML, where you're trying to get things working, but getting little in return for that effort. XLST is supposed to be the glue that keeps it all together, but there is no "it" to keep together.
XML also does not play very nice with streaming technologies.
I suspect that eventually XML will make a comeback. Or maybe another SGML dialect. But that time is not now.
I think the simplest explanation is that developers used it and did not like it.
The pro-XML narrative always sounded like what you wrote, as far back as I can remember: The XML people would tell you it was beautiful and perfect and better than everything as long as everyone would just do everything perfectly right at every step. Then you got into the real world and it was frustrating to deal with on every level. The realities of real-world development meant that the picture-perfect XML universe we were promised wasn't practical.
I don't understand your comparison to containerization. That feels like apples and oragnes.
HTML was conceived as a language for marking up a document that was primarily text; XML took the tags and attributes from that and tried to turn it into a data serialization and exchange format. But it was never really well suited to that, and it's obvious from looking XML-RPC or SOAP payloads that there were fundamental gaps in the ability of XML to encode type and structure information inline:
Compared to this, JSON had string and number types built in: I don't think this is the only factor, but I think XML had a lot of this kind of cognitive overhead built in, and that gave it a lot of friction when stacked up against JSON and later yaml... and when it came to communicating with a SPA, it was hard to compete with JS being able to natively eval the payload responses.To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param, this is why we ended adopting openapi for describing http interactions and iirc jsonrpc specifically can also be described with it. At least in the schema part no one would say it is ambiguous, also one does not need do heavier parses, the obj is a tree, no more checking on scaping strings, no more issues with handcoded multiline strings, it is dropped the need to separate attributes with commas as we know the end tag delimits a space and so on.
> To be fair I cannot trust your shape in your jsonrpc, I am not sure if id is truly an integer or if you sent me an integer by mistake, same as params or even the payload of the params' param
In practice, it doesn't matter.
If the JSON payload is in the wrong format the server rejects it with an error.
If the server sends an integer "by mistake" then the purists would argue that the client should come to a halt and throw up an error to the user. Meanwhile the JSON users would see an integer coming back for the id field and use it, delivering something that works with the server as it exists today. Like it or not, this is why JSON wins.
Schema defined protocols are very useful in some circumstances, but in my experience the added overhead of keeping them in sync everywhere and across developers is a lot of overhead for most simple tasks.
Putting the data into a simple JSON payload and sending it off gets the job done in most cases.
Yeah this is the issue. I spent tons of time writing code that would consume xml and turn it into something useful.
It’s a mediocre data storage language.
> developers used it and did not like it.
This makes sense.
However, there are two ways to address it:
1) Work towards a more advanced system that addresses the issues (for example, RDF/Turtle – expands XML namespaces to define classes and properties, represents graphs instead of being limited to trees unlike XML and JSON)
2) Throw it away and start from scratch. First, JSON. Then, JSON schema. Jq introduces a kind of "JSONPath". JSONL says hi to XML stream readers. JSONC because comments in config files are useful. And many more primitives that existed around XML were eventually reimplemented.
Note how the discussion around removing XSLT 1 support similarly has two ways forward: yank it out or support XSLT 3.
I lean towards Turtle replacing XML over JSON, and for XSLT 3 to replace XSLT 1 support in the browsers.
> And many more primitives that existed around XML were eventually reimplemented.
Don't miss that they were reimplemented properly.
Even XML schemas, the one thing you'd think they were great at, ended up seeing several different implementation beyond the original DTD-based schema definitions and beyond XSD.
Some XML things were absolute tire fires that should have been reimplemented even earlier, like XML-DSIG, SAML, SOAP, WS-everything.
It's not surprising devs ended up not liking it, there are actual issues trying to apply XML outside of its strengths. As with networking and the eventual conceit of "smart endpoints, dumb pipes" over ESBs, not all data formats are better off being "smart". Oftentimes the complexity of the business logic is better off in the application layer where you can use a real programming language.
> Even XML schemas, the one thing you'd think they were great at
Of course not! W3C SHACL shapes, on the other hand...
schema.org is also a move in the right direction
The simplest explanation is that attributes were a mistake. They add another layer to the structure and create confusion as to where data is best stored within it.
XML without attributes probably would have seen wide and ready adoption.
I see it as the opposite. Attributes weren’t used enough. The result was unnecessarily nested code.
“Keep things flat” is current good advice in terms of usability. That means favor attributes over children.
I agree. A sibling thread showed an example of XML above containing params/param/value/int/ nodes which with attributes could just be <param type=int>.
I do agree that attributes/data was always a huge contention point on where things should go and caused confusion and bikeshedding.
I also saw a bit of this in the React/JSX community with decisions like render props, HoC, etc where it took a bit to stabilize on best practices.
While i think a lot of xml was a bad idea, some of the issues are not instrinsically the fault of XML but some really poor design decisions by people making xml based languages.
They tended to be design by comittee messes that included every possible use case as an option.
Anyone who has ever had the misfortune of having to deal with SAML knows what i'm talking about. Its a billion line long specification, everyone only implements 10% of it, and its full of hidden gotchas that will screw up your security if you get them wrong. (Even worse, the underlying xml-signature spec is literally the worst way to do digital signatures possible. Its so bad you'd think someone was intentionally sabotaging it)
In theory this isn't xml's fault, but somehow XML seems to attract really bad spec designers.
Part of the problem was it came in an era before we really understood programming, as a collective. We didn't even really know how to encapsulate objects properly, and you saw it in poor database schema designs, bizarre object inheritance patterns, poorly organised APIs, even the inconsistent method param orders in PHP. It was everywhere. Developers weren't good at laying out even POCOs.
And those bizarre designs went straight into XML, properties often in attributes, nodes that should have been attributes, over nesting, etc.
And we blamed XML for the mess where often it was just inexperience in software design as an industry that was the real cause. But XML had too much flexibility compared to the simplicity of the later JSON, meaning it helped cause the problem. JSON 'solved' the problem by being simpler.
But then the flip side was that it was too strict and starting one in code was a tedious pita where you had to specify a schema even though it didn't exist or even matter most of the time.
Nah, we still have all those issues and more.
The hard truth is that XML lost to the javascript-native format (JSON). Any JavaScript-native format would have won, because "the web" effectively became the world of JavaScript. XML was not js-friendly enough: the parsing infrastructure was largely based on C/C++/Java, and then you'd get back objects with verbose interfaces (again, a c++/java thing) rather than the simple, nested dictionaries that less-skilled "JS-first" developers felt at ease with.
The thing is, JSON is even superior in C++.
It's a dumber format but that makes it a better lingua franca between all sorts of programming languages, not just Javascript, especially if you haven't locked in on a schema.
Once you have locked in on a schema and IDL-style tooling to autogenerate adapter classes/objects, then non-JSON interchange formats become viable (if not superior). But even in that world, I'd rather have something like gRPC over XML.
A dumber format works great for dumber protocols like RPC. When you're trying to represent something complex like a document, JSON is crap. Imagine the JSON equivalent of HTML. Then imagine editing it by hand.
"Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
> When you're trying to represent something complex like a document, JSON is crap.
I agree, but let's be honest, how often does this actually come up for data interchange. Because the situations where you want a human-editable document that is also computer-legible are fairly few in number. Prose in office documents, human-written documentation for code, config files.
For things where computer programs are driving the show (which is most the time, today), you want interchange designed for programming languages, whether that's JSON, CSV, gRPC, or what have you.
This even applies to documents that are completely computer-generated: get the inputs into an appropriate data structure using easy interchange formats, and then render to the output document (HTML, XML, LaTeX, etc.).
> Data" lives on a spectrum of simple to complex; most is simple; JSON is great for that. But not for everything.
Fully agreed. But even where you do have documents, XML is not always the right thing either, which is why there are other markup formats in wide usage like TeX and Doxygen/Javadoc-style comments. XML seems best aligned to things like office document formats or other rich text where it makes sense to want to wrap some human text inside some computer-visible markers.
> how often does this actually come up for data interchange
Pretty much anywhere with text-heavy payloads? It's quite a lot, I think, but still dwarfed by the number of cases where system A needs to perform some sort of RPC-like communication with system B.
I just think that there is plenty of room in the world for both approaches.
that's the thing, XML should have become javascript native so that we could write inline HTML more easily like JSX from react allows us to do.
It did somewhat. It was called E4X.
more like it almost did. bummer. thanks for the pointer. sad to find out that the attempt was made but rejected. i wonder why.
Essentially, people didn't use it.
I think the reason is that it solved the "problem" of integrating XML into JavaScript, as if being good at XML was an end in itself. Once XML started being replaced by JSON in earnest, what was the pressing need for E4X? Doing stuff in SOAP or WS-* presumably, but that wasn't a common use case in browser JavaScript, though it might have come in handy if Node.js took off a bit earlier.
JSX took off because it helped frontend developers solve problems outside of JSX. Look at examples of its use and it's heavily intertwined with the rest of what you'd see on a webpage (HTML, JS and CSS), and you never get the sense that JSX is a "self-licking ice cream cone".
This is the abstract idealism I was talking about: Every pro-XML person I've talked to wants to discuss XML in the context of a hypothetical perfect world of programming that does not exist, not the world we inhabit.
The few staunch XML supporters I worked with always wanted to divert blame to something else, refusing to acknowledge that maybe XML was the wrong tool for the job or even contributing to the problems.
Regarding containerization, XML wouldn’t just be a noun, but a verb (like in XSLT). You would define your remote procedures in XML.
Imagine if instead of the current Dockerfile format, we used XML, which was dynamically generated from lists of packages, and filtered and updates according to RSS feeds describing CSVs and package updates.
I’m not saying this is anything other than strange fantasy. And not a particularly nice fantasy either.
XML failed because it forced devs to spend tons of unproductive time on it
I think a key factor is: XML offers so many ways to serialize, you always have to decide in the individual case what the structure should be, what's an attribute, what's Text content, what's it's own attribute and those are important choices having impact on later changes.
With JSON you can dump data structures from about any language straight out and it's okay to start toying around and experimenting. Over time you might add logic for filtering out some fields, rename others, move stuff a little around without too much trouble.
Also quickly writing the structure up by hand works a lot faster in any editor, without having to repeat closing tags (while at some point closing brackets and braces will take their tribute)
However I agree: once you got the XML machinery, there is a lot of power in it.
I get your point but JSON still has a lot of the same problems; for example, no standard way to represent a timestamp. Despite being "javascript object notation" it's missing lot of javascript's types.
> I've seen it in bits and pieces. It would have been beautiful.
XHTML being based on XML tried to be a strict standard in a world where a non-strict standard existed and everybody became just very much aware on a daily that a non-strict standard is much easier to work with.
I think it's very hard to compete with that.
Seconded. I spend a whole lot of effort making my early 2000s websites emit compliant XHTML because it seemed like the right thing to do, and the way we were inevitably heading. And then I — and apparently almost everyone else, too, at the same time — realized it was a whole lot of busywork with almost nothing to show for it. The only thing XHTML ever added to the mix was a giant error message if you forget to write "<br/>" instead of "<br>".
Know what? Life's too short to lose time to remembering to close a self-closing tag.
About the time XHTML 1.1 came along, we collectively bailed and went to HTML5, and it was a breath of fresh air.
I don't understand this sentiment. Never have. I've doubted myself for years that I'm mistaken that this is how XHTML really fell out of favor despite it being what I recall reading at the time. A modern web developer is writing in javascript or typescript, which is going to make you correctly close your curly braces and parentheses (and so much more with typescript).
Then React introduced faux-XML as JSX except with this huge machinery of a runtime javascript virtual DOM instead of basic template expansion and everyone loves it? And if this react playground I've opened up reflects reality, JSX seems to literally require you to balance opening/closing your tags. The punch-line of the whole joke.
What was the point of this exercise? Why do people use JSX for e.g. blogs when HTML templating is built into the browser and they do nothing dynamic? For many years it's been hard to shake the feeling that it isn't some trick to justify 6 figure salaries for people making web pages that are simple enough that an 8 year old should be up to the task.
That same nagging feeling reassures me about our AI future though. Easy ways to do things have been here the whole time, yet here we are. I don't think companies are as focused on efficiency as they pretend. Clearly social aspects like empire building dominate.
> I don't understand this sentiment. Never have.
It was pretty evident when it happened, particularly because XHTML in some browsers was parsed with a sloppy HTML parser, and in some with an XML parser which was strict. Guess what happened. Tons of invalid XHTML was out there and it made it impossible to parse as XML.
And some of the sloppy parsers rejected valid XML that the strict parsers accepted.
Combined with Firefox and MSIE having different combinations of HTTP headers and doctype declarations to specify XHTML mode, it was way too hard to emit one single doc that was viewable on all common browsers. For a while my life involved regularly chasing down random issues that suddenly made our customers' browsers show an error page instead of the content, even when it was actually valid and passed all validators.
I don't miss this.
> Why do people use JSX for e.g. blogs when HTML templating is built into the browser and they do nothing dynamic?
...but real HTML templating isn't built-in to HTML[1]. Its absence for these 30 years is as huge a mystery as why there's no combobox input element (combination textbox+drop-down) or <select>'s limitations.
[1] What I mean by this is that JS+DOM still has no simple way of escaping HTML in a string. It's insane.
To elaborate: if you have a some arbitrary strings (unsanitized user input): `headerText` and `firstParagraph` that you want to render to a HTML fragment like `<h2>{headerText}</h2><p>{firstParagraph}</p>` then the only real way of doing this safely is by using the (archaic and verbose) DOM Level 1 methods (document.createElement, textContent = 'text', etc) which somehow always turn what-should-be a 1-liner pure-function in any sane language to a 10-line function with side-effects (...and as it's 2025 then it will probably be async too).
When JS added support for template-literals, I was excited that this might mean an end to the embarrassing problem, but because it didn't ship with HTML-escaping it means it's useless for that purpose - unless you're going to go through the effort to implement a full "tagged template" with a parser function, which I assume would handle the DOM parts.
It could be that we have drastically different ideas of "easy way to do things". To me, XSLT has never remotely resembled an easy way to do things. It seemed like a weird, difficult, almost deliberately obtuse horse designed by committee that technically worked but in a horrifying kind of way, like finding that someone write a C compiler Bash. Wow, it's cool that someone was able to do it at all, but I can't imagine ever wanting to jump on that train.
The problem with XML is that it’s horrible to manually read and write, and it takes more effort to parse too. It’s a massive spec which contains footguns (a fair few CVEs exist just because of people using XML on publicly accessible endpoints).
Now I do think there is a need for the complexity supported by XML to exist, but 99% of the time JSON or similar is good enough while being easy to work with.
That all said, XHTML was amazing. I’d have loved to see XHTML become the standard for web markup. But alas that wasn’t to be.
XHTML was too rigid - as a user agent it should try to render a document, rather than tell the user: "tough, the developer screwed up".
So XHTML lost to the much more forgiving HTML.
There was an idea to make a forgiving XML for web use cases: https://annevankesteren.nl/2007/10/xml5 but it never got traction.
I saw the rigidity of XHTML as an asset rather than a problem.
But I do agree that I’m likely in the minority of people (outside of web developers at least) that thought that way.
I doubt this is really meaningful. It's not like browsers are forgiving about malformed javascript. We live with "tough, the developer screwed up" every day.
I think you're getting at a very often discussed ebb and flow between being extremely controlled vs extremely flexible. XML was astounding compared to system specific proprietary systems, and then as the need for formalism grew people wanted something simpler... And now you see the same thing growing with JSON and the need for more rigor. I personally think there are many forces to all of this, just the context at the time, prevailing senses of which things are chores and which aren't, companies trying to gain advantage, but probably most importantly is that the vast majority of people have a subset of historical information about systems and computer science, myself included, yet we have to get things done.
I legitimately tried my best to like XLST on the web back in the day.
The idea behind XLST is nice — creating a stylesheet to transform raw data into presentation. The practice of using it was terrible. It was ugly, it was verbose, it was painful, it had gotchas, it made it easier for scrapers, it bound your data to your presentation more, and so on.
Most of the time I needed to generate XML to later apply a XLST style sheet, the resulting XML document was mostly a one off with no associated spec and not a serious transport document. It begged the question of why I was doing this extra work.
Making your data easy to scrape is part of the point (or just more generally work with). If you're building your web presence, you want people to easily be able to find the data on your site (unless your goal is platform lockin).
The entire point of XSLT is to separate your data from its presentation. That's why it made it easy to scrape. You could return your data in a more natural domain model and transform it via a stylesheet to its presentation.
And in doing so it is incredibly concise (mostly because XPath is so powerful).
XML was a great idea but the markup was tedious and verbose.
JSON is too simplistic.
Something built from s-expressions would probably have been ideal but we've known that for 70 years.
What would that look like?
Look up "SXML" for an example of what that might look like. There's many other ways to do it, though.
> I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Whoa, that doesn't have anything to do with the dislike for XML. We dislike XML because its use is heavily correlated with IBM java tech stack, and that is a complete disaster in usability and project management.
IBM WebSphere with all its fragile XML configuration files, which can't be edited by hand because everything breaks if you try, are my reason to avoid XML since, and if I ever have to choose, I will choose against XML.
Containerisation became a normal practice about a decade after I and the other developers I know, started to avoid XML.
> I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
Not sure how that is true. XML is a specification for a data format, but you still need to define the schema (i.e., elements, attributes, their meaning). It's not like XML for web pages (XHTML?) could also serve as XML for Linux container descriptions or as XML for Android app manifests.
Sometimes it gets lost that XML is a document description language like HTML.
Yeah this 100%. JSON took off only partly because it has less tedious syntax. The other big reason is that its data model is actually what you really want 99% of the time. XML has to be squashed awkwardly into the normal object-based data model that most programming languages use.
I actually rather like XML(asterisk) But this is one of it's warts, It wants to be two things, A markup language, it's in the name and arguably where it should have stayed, and an object notation. This is where you start to question some of XML's fundamentals, stuff like why is it redundant? When do you stick data in attributes? Or is it better to nest tags all the way down?
Asterisk: except namespaces, I loathe those, you are skipping happily along chewing through your XML, xpathing left and right, and then find out some psychopath has decided to use namespaces, and now every thing has become super awkward and formal.
Namespaces are essential whenever you want to insert contents defined by one schema into “payload” or “application-defined” elements of another schema. There are also more complex scenarios where attributes from one schema are used to annotate elements from a different schema.
Well, I guess we could do it like libraries in C-land and have every schema add its own informal identifier prefix to avoid name collisions. But there’s a reason why programming languages moved to namespaces as an explicit notion.
>XML also does not play very nice with streaming technologies.
Not sure why just as good as JSON, if you are going to stream and parse you need a low level push or pull parser not a DOM just like JSON. See SAX for Java or XmlReader / XmlWriter in .Net.
XSLT 3 even had a streaming mode I believe which was badly needed but had constraints due to not having the whole document in memory at once.
I liked XSLT but there is no need for it, javascript is good enough if not better, many times you needed to do a xslt script tag to get some thing done it couldn't do on its own anyway, might as well use a full language with good libraries for handling XML instead. See Linq to XML etc.
Right, both sort of suck at streaming, something about being closed form tree structures would be my guess(strictly speaking, you need to close the tree to serialize it, so no clean way to append data in real time, best you can do is to leave the structure open and send fragments). Having said that, I am not really sure what a good native streaming format would look like. Best guess is something flatter, closer to CSV.
>Right, both sort of suck at streaming, something about being closed form tree structures would be my guess(strictly speaking, you need to close the tree to serialize it, so no clean way to append data in real time, best you can do is to leave the structure open and send fragments).
Again don't really agree, its just most developers don't seem to understand the difference between a DOM or parsing JSON into a full object vs using a streaming reader or writer so they need to be hand fed a format that forces it on them such as line based CSV.
Maybe if JSON and XML allowed top level multiple documents / objects it would have helped like JSON lines.
XML standards did "take hold". You couldn't get away from XML for a while. Then everyone came to their senses, thank god.
If XForms was released on browsers today, it would be hailed as a revolutionary technology. Instead, it is just one of the many things thrown away, and even now 20 years after the WHATWG took over we cannot even do a PUT request without Javascript.
What a pity.
For those unaware of XForms: https://www.youtube.com/watch?v=2yYY7GJAbOo
> I would blame the adoption of containerization for the lack of interest in XML standards, but by the time containerization happened, XML had been all but abandoned.
It got abandoned because it sucks. New technology gets adopted because it's good. XML standard were just super meh and difficult to work with. There's really not much more to it than that.
I don’t follow why docker killed XML.
Google didn't want XML to win.
XHTML would have made the Semantic Web (capital letters) possible. Someone else could have done search better. We might have had a proper P2P web.
They wanted sloppy, because only Google scale could deal with that.
Hopefully the AI era might erode that.
The Semantic Web was never going to win. It does not make sense on a fundamental level.
XHTML's failure had nothing to do with it, and is basically unrelated. Even if xhtml won i fail to see how that would have helped semantic web in any way shape or form.
XML died because it sucks. Everyone who had to deal with it back in the day jumped to YAML and/or JSON as quickly as they could. Google didn't cause that, but because they're a search engine they followed it.
I don’t recall Google being the ones to kill XHTML. Got any references to back that claim up?
XSLT currently provides a lot of value, as the browser can use it to transform documents directly, and it is exposed to JavaScript for scripting. Exploring it recently, including creating a PWA with XML sources reminded me why I like developing on the web. It made me think--RSS feeds can be PWA's now--right?
XML/XSLT/CSS/JS: https://kherrick.github.io/x-ml-data/2025/01/exercising-xslt...
XHTML/CSS/JS: https://kherrick.github.io/x-app/2025/01/exercising-xslt/
It seems like XSLT 3.0 would open up a lot of new opportunities and patterns, especially if it continues to work with existing standards, as the current version does. The Web Platform is so cool.
Yes. That's the right solution for the even playground regarding the situation:
Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like <xsl:text disable-output-escaping="yes"> having open issues" ).
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user !
Chrome clearly outcompeted Firefox despite Firefox’ faster XSLT implematation, so perhaps the performance of a feature which is almost never used is not that significant either way?
Chrome is outcompeting (or cripling) Firefox - in taking control from the user, payed by the user - right now, with your comment all backward (and catch 22, cross-browser functionality bugs never to be fixed).
All downvoted ? If not performance of [ONE] feature like JS engine, what would make Chrome better ? (crippling others). JS is used so much only because all other options are kept broken (since Microsoft JS XMLHttpRequest - for applications not documents, being the lowest common denominator - against few bugs that needed to be fixed, not much changed) - otherwise there will be no need of JS for documents processing and less energy wasted - and the bill is payed not by corporations but by users, with extra tracking taxes.
Are you arguing XSLT can do anything JS can do? Because that is obviously not true.
Chrome mostly can do anything Firefox can do since removing its "legacy extensions", so Firefox has to remove XSLT too - as Google can't afford it being not helpful for tracking - and can compete only with its JS engine - so XSLT, if to stay, could in the future only be reimplemented in JS polyfills no more, making it less useful, not cached, not transparent - to let Chrome 'outcompete' others again, race to the bottom, everything looks like a nail.
Hopefully that could be enough to complete the evidence to split Google into pieces in antitrust case - or realizing that will make Google to back off ?
But JS can't do things in the way XSLT so far still can, transparently etc. operating at differrent level ( e.g. https://news.ycombinator.com/item?id=45000600 )
for documents, stylesheets are enough, KISS.
no, it don't wont :) that's the point
---
WWW made of interlinked documents,
yet making it to be interlinked code too.. may not last, as codes like changing and finding new ways.
Fancy stuff as JS may be very useful and I like it too, momentary, when well applied, but it needs: an effort to use it, keep working, adapting, if interoperating, all specific, for the purpose - and power, can't open 1000s tabs. Different kind of being. More fun, like with the hammer for everyhthing - not shy like XSLT trying be transparent.
If the P in SPA exists to load your app, then why care? If you’ve noticed the herd thin as SSE and hypermedia trim split ends, then you may see the utility in open web tooling.
Didn't we just have the opposite conversation?
https://news.ycombinator.com/item?id=44909599
This is the positive space of that negative framing.
Things like XML and XSLT were useful and nice when I used them in 2004. But that's more than 20 years ago now. It's not something I encounter regularly in modern tech stacks. How widely used is this stuff in browsers at this point? I don't think browsers should be burdened with a lot of complex solutions to serve a few minority/niche use cases.
And even then, using this stuff server side was more common than relying on browsers. XHTML was still being actively pushed and Whatwg kind of made that go away in favor of HTML5. Whatwg was a breadth of fresh air in the whole captial S and lower case s semantic web debates between XML purists on one hand and people just trying to create browsers that worked on the other hand. The latter camp won by virtue of eventually producing browsers that implemented Whatwg standards and then world+dog voting with their feet and making use of those browsers and standards. The whole debate just fizzled out after that.
XSL support in browsers is part of some of the reasons WhatWG was created: a lot of poorly thought through and half specified features being proposed by and rushed through the W3C. Which was putting browser makers on the spot having to support all that in a way that worked well across browsers. The job of "lets just sit down and specify this stuff properly" is why Whatwg was created. That's a job that took many years and it created the modern web and finally enabled high levels of interoperability between browsers.
And there are other mechanisms available to developers that are well endorsed by browser makers and standards. Including using whatever libraries you want in WASM form and running them in a sandboxed environment in a browser. Which is also complex of course but at least is being widely used and well specified at this point. I don't see many compelling reasons for this stuff to live outside of that sandbox.
[flagged]
[flagged]
[flagged]
[flagged]