Rather than struggling/withering, it's actively being killed. Efforts are underway to completely remove XSLT support from browsers, due to the poor state of libxml2 and a lack of any new maintainer stepping up.

▲

fergie 5 days ago | parent [-]

Right, but AKAIK its _still_ being maintained on a voluntary basis. Thats nuts, and its not clear why, say, Chrome or Firefox wouldn't want to take over XSLT/libsml2 development, particularly if they won market share from stuff like React, and created a developer acquisition pipeline for their respective ecosystems.

▲

arp242 5 days ago | parent | next [-]

> its not clear why, say, Chrome or Firefox wouldn't want to take over XSLT/libxml2 development

Very few people actually like XSLT, presumably including the Chrome and Firefox devs. I know XSLT has its share of supporters and that's fine. I'm not here to argue to merits of XSLT – or lack thereof – but we need to be honest about this. They are the proverbial Black Metal fans; everyone else just thinks it's bloody noise.

In addition, many people have grown towards the idea that importing these large C libraries for little used features is just not a good idea in the first place. And that makes libxml and libxslt a dead end. The entire business with XSLT was kicked off by a bunch of security bugs.

Finally, I think a decent case can be made to slim down the "web platform" a bit. If you want XSLT you can still "bring it yourself", but does every browser need to implement it to be "standards compliant"? Seems like a bad trade-off to me. It's a win for newer browsers like Servo or Ladybird if they don't need to worry about XSLT.

So in short, it's not just a problem of "adding some more people to libxml", although obviously that is a problem.

	▲	conartist6 4 days ago \| parent \| next [-]
		Just for the sake of example I'm one of the people who would be a candidate to take over development, but same as anyone else I have little desire to be stuck maintaining unnecessarily complex functionality. Instead I've chosen to work on reimplementing XML and its utilities from the ground up without making the same errors that made XML so miserable to users and implementers both...
	▲	fergie 4 days ago \| parent \| prev [-]
		> a decent case can be made to slim down the "web platform" a bit. If you want XSLT you can still "bring it yourself" Completely agree, but there remains the massive unsolved issue of templating in HTML (at the moment XSLT is the only way to run a templated HTML website on s3 without a massive pile of javascript).

▲

omcnoe 5 days ago | parent | prev [-]

They don’t want to because they don’t see any bright future for the technology even if it’s better maintained. XML/XSLT isn’t trendy anymore, nobody is building new apps on it. It is never going to win market share from react - it’s too baroque and dated.

▲

epolanski 5 days ago | parent [-]

> It is never going to win market share from react

Not sure what React has anything to do with this.

XSLT was pretty much never used as a rendering platform but for XML-data processing.

As JSON became the standard of API communication in early 2000s (less powerful, but also much less verbose and easier to manipulate in JS) XSLT became less relevant.

▲

omcnoe 5 days ago | parent [-]

Parent comment mentioned react, I can sorta see the comparison if you squint. But I disagree with their assertion that a better maintained XSLT could compete.

	▲	epolanski 5 days ago \| parent [-]
		I missed it. In any case, I'm not sure I agree with you, while JavaScript and CSS are composable out of the box HTML really lacks a native, fully declarative, composable way to build documents.