To me XSLT came with a flood of web complexity that led to having effectively only 2 possible web browsers. It seems a bit funny because the website looks like straight out of the 90s when "everything was better"
It was not rendering that killed other browsers. Rendering isn't the hard part. Getting most of rendering working gets you about 99% of the internet working.
The hard part, the thing that killed alternative browsers, was javascript.
React came out in 2012, and everyone was already knee-deep in earlier generation javascript frameworks by then. Shortly after, Google would release the V8 engine which was able to bring the sluggish web back to some sense of usable. Similarly, Mozilla had to spend that decade engineering their javascript engine to claw itself out of the "Firefox is slow" gutter that people insisted.
Which is funny because if you had adblock, I'm not convinced firefox was ever slow.
A modern web browser doesn't JUST need to deal with rendering complexity, which is manageable and doable.
A modern web browser has to do that AND spin up a JIT compiler engineering team to rival Google or Java's best. There's also no partial credit, as javascript is used for everything.
You can radically screw up rendering a page and it will probably still be somewhat usable to a person. If you get something wrong about javascript, the user cannot interact with most of the internet. If you get it 100% right and it's just kind of slow, it is "unusable".
Third party web browsers were still around when HTML5 was just an idea. They died when React was a necessity.
Conveniently, all three of the major JS engines can be extracted from the browsers they are developed for, and used in other projects. Node and Bun famously use V8 and the WebKit one, and Servo I believe embeds SpiderMonkey.
If you want to start a new browser project, and you're not interested in writing a JS engine from scratch, there are three off-the-shelf options there to choose from.
I have the same mixed feelings. Complexity is antidemocratic in a sense. The more complex a spec gets the fewer implementations you get and the more easily it can be controlled by a small number of players.
It’s the extend part of embrace, extend, extinguish. The extinguish part comes when smaller and independent players can’t keep up with the extend part.
A more direct way of saying it is: adopt, add complexity cost overhead, shake out competition.
It's far from dead, though. XML is deeply ingrained in many industries and stacks, and will remain so for decades to come, probably until something better than JSON comes along.
There was fresh COBOL code written up until early 1990s too, long past its heyday.
Thing is you couldn't swing a dead cat in 00s without hitting XML. Nearly every job opening had XML listed in requirements. But since mid-2010s you can live your entire career without the need to work on anything XML-related.
But it’s still there and needs to be supported by the OS and tooling. Wether you edit it manually isn’t relevant (and as counterpoint, I do it all the time, for both apps and launchd agents).
There's still epub and tons of other standards built on xml and xhtml. Ironically, the last epub file I downloaded, a comic book from humble bundle, had a 16mb css file composed entirely of duplicate definitions of the same two styles, and none of it was needed at all (set each page and image to the size of the image itself, basically)
On the web. I, among other things, make Android apps, and Android and XML are one and the same. There is no such thing as Android development without touching XML files.
I did Android Developer Challenge back in 2008 and honestly don't remember doing that much of XML. Although it is the technology from peak XML days so perhaps you're right.
It has, I think, one nice feature that few markups I use these days have: every node is strongly-typed, which makes things like XSLT much cleaner to implement (you can tell what the intended semantics of a thing is so you aren't left guessing or hacking it in with __metadata fields).
... but the legibility and hand-maintainability was colossally painful. Having to tag-match the closing tags even though the language semantics required that the next closing tag close the current context was an awful, awful amount of (on the keyboard) typing.
