They were wrong about one thing: tooling matters.

The XHTML/XML/XSLT tooling was bad, and XSLT was hard to reason about. That meant that amateurs had no way to learn it, and those amateurs went to school and became the workforce.

The web became a winner because it was easy to get something working. And then Google made it a mission to make great developer tools in everyone's hands for free.

I think in 2026 we could build the tooling around a better experience, but it would require thinking about the developer experience first.

You could do some awesome things with XML/XSL. My favorite was RSS feeds or OPML collections of RSS feeds (both flavors of XML) calling an XSL transformation when viewed in a web browser instead of mined by computers for data; same with TEI files, although that was a bit more arcane. The idea was that you'd have one data file for machine use and a way to present that data to humans as a web page.

But, as a stack, the XML/XSL/XPath/etc combination was weak because XSLT was hard to comprehend and never updated. No browser supports XSLT 2 or 3; they froze support with 1. XSLT 2 was 2007, a year before HTML 5 was a thing, yet it never got picked up by browsers. Javascript was just easier to understand than XSLT. Development of XHTML was also glacial, and people wanted new tags, especially for video.

I can't help but agree, and sometimes I think about the alternate version of the web where XML realized its full potential as the dominant technology. The obvious problem with XML is that the syntax is so verbose and redundant that it's only barely human-writable, but this is 100% a solvable problem.

yet people will say that HTML5 is all you need or something