Hacker News

Well said. I once had the displeasure of trying to write some code in XSLT (it had to fit in with existing XSLT code). It had to be the worst programming language I'd ever seen, with the possible exception of assembler. First, who decided that XML was a good format to write a programming language in? Punch cards would have been better. And second, trying to debug it was embarrassingly difficult.

That’s basically what happened with MathML a decade ago. Chromium had briefly had an implementation (M24 alone!), Firefox had an excellent implementation, and Safari had a decent implementation; there was very little usage. Chromium proposed removing it. There was much kerfuffle. When the dust settled, MathML won. MathML Core was defined, Igalia contributed a robust MathML implementation to Chromium, Safari tightened their implementation up, and people started actually using it a lot more.

Around the same time, Google tried to deprecate SMIL (SVG animation tech), which would probably have led to its removal after some time. This also failed, and it’s used more than it was then (though CSS animations are probably quite a bit more popular, and have over time become more capable), probably because now all engines support it robustly (MSHTML and EdgeHTML never did).

I hope that we’ll get a more formal commitment to XML and XSLT, and XSLT 3 in browsers, out of this.

It wasn't Google. The original proposal came from Mozilla, and apparently all the browser vendors want to be rid of it.

It’s a parallel universe Lisp/Rust as far as HN goes.

[dead]

I find massive blobs of XML easier to grok than massive blobs of JSON, esp well-designed XML with namespaces and use of attributes. XML is self documenting.

JSON is just a homogeneous unnamed bunch of braces and key-val pairs that you loose yourself in once you are several MB in and deeply nested. Need to resort to CLI tools like jq or hunt for the schema or docs.

Massive blobs of YAML, well - they should be simply categorized as a war-crime.

It is “just code.” It’s good at what it does too.

Although for my purposes, I find myself reaching for xquery a lot more often which is a very good and elegant programming language and template language although it was billed as “SQL for XML.”

Sure, it's so much better to be writing massive blobs of YAML.

There just seems to be some misguided human impulse to take every data serialization language and force it to be a programming language, instead of just using a programming language.

XML and XSLT are a bad fit in many common uses, that's why the argument is frustrating. If you are almost always working with projects where you own the frontend and the backend, just stick with JSON and RPC.

Agreed. I tried XSLT once. I made an XSLT for RSS. Coding in XSLT really sucked.

Current state of things is a mixed bag, in my opinion. XSLT wasn't perfect, and XML required a lot of repetition and neither got the amount of scrutiny both deserved to advance past their own inconvenience. But a lot of what we have today has just as many drawbacks, and that _despite_ WHATWG and Google hawking over it all. XML had namespaces, which alone were quite a potent feature that allowed to manage _semantics_ of data with more rigor and flexibility -- compared to the in my opinion amateur-ish "custom elements" HTML 5 approach, and how Apple refuses to implement parts of the spec., because they "don't believe in inheritance" (I am being liberal but those who know know). Then there is the HTML 5 parser itself -- "for the masses" -- with its idiotic and incomprehensible rules that are element specific, for which reason noone ever remembers these. Forgot a `</p>`? No problem, you can discover your omission after you've shipped! HTML 5 parser never aborts!

> 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.

So does every other open source XSLT implementation, along with XPath/XQuery 3x. Most of them at best support 2x or 1x with some 2x-compatible extensions, but I'm not aware of any that fully support the 3x variants, besides Xidel (XPath/XQuery 3.0). The proprietary Saxonica is the go-to at the moment.

XSLT and XQuery 3.0 can have type annotations and implementations can even type check based on a XSD schema. That should help with adapting to version changes in input and output formats.

I'm on the distributor side, I used to fantasize about using XSLT to produce all the different XML formats (beyond DDEX, like Apple, etc) from one house format, but that was probably a bad idea!