The article's example shows the main reason (besides having old libraries shipped with Java) why XSLT didn’t have a significant adoption: UX/DX.

The JSON transformation example is quite simple, and you can accomplish it with one or two lines of JS. But the XLST is unreadable, starting with tons of namespace imports.

The usual argument is that a good UI can fix that, but that’s false. So using XSLT for general data transforms is very problematic: it's hard to read, with no debugging tools, and it’s also hard to build a UI tool that simplifies that for the “citizen integrator” (the segment of people who have technical knowledge and take care of doing integrations but are not experienced with programming).

(Around 2017, I worked for a company that created its own data transformation tool, so I designed the UI editor and did user research of people using transformation languages in different scenarios.)

> The article's example shows the main reason (besides having old libraries shipped with Java) why XSLT didn’t have a significant adoption: UX/DX

I wonder if react would be popular today if it started out with the UX/DX we have today. It started out as a comparatively simple component-based library for rendering templates in the browser. It got popular and built a huge community before becoming the complete DX mess that it is today.

I lived and breathed XSLT back in the day for 3 projects over 2 years. Hell, I was the company's "XML evangelist" and spoke at XMLConf in San Diego.

I would never go back.

XSLT's "coding UX" is atrocious. Simple things "look complex" and complex things "look obfuscated".

As mentioned in the parent post, there's also this consistent "low leverage" to the code so you feel as if you're typing a lot for little impact.