Decades ago, I worked on the XCB library (the replacement for Xlib). I replaced the M4 macros used to generate all the X protocol bindings with XML protocol definitions and XSLT to do code generation.
The XML turned out extremely well, and it's still being used today, such as for bindings in several other languages.
Someone rewrote my XSLT in Python, and I cheered them on, because the result was much more readable, not least of which because the fundamentally procedural steps could be written in a procedural language with a good syntax, rather than XSLT's pure-functional language that suffered from being embedded in XML.
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.
nah. its a transform for XML and its super useful when you need it. People such as yourself who claim its not a great programming language are probably not trying to use it for the right thing.
I was using it to transform DocBook XML into LaTeX, based on an existing tool that used xslt code to do just that (https://sourceforge.net/projects/dblatex/). We had to modify the existing xslt code to allow for enhancements to DocBook that accommodated some linguistic structures (like interlinear text).
So yes, we were using it for exactly the right thing: transforming XML.
On what grounds do you contend that it's not a programming language? There are other declarative programming languages, like Prolog, so I fail to see how the fact that it's a "declarative transform" makes it any less of a programming language.
Is XSLT enjoying the equivalent of Streisand Effect? Ever since news came out of Google wanting to rid Chrome of XSLT support, there has been a number of XSLT-related news here. I am not complaining, I think XSLT deserves a second life, it hasn't had the scrutiny it deserves, nor its "15 years of fame".
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.
Browser makers trying to kill XSLT is not new: Chrome had intents to deprecate and remove XSLT in 2013 and 2015 (which both failed).
Each time so far, there’s been movement for a while, significant pushback, and the one who was championing removal realises it’s hard, and quietly drops it. Smaug from Mozilla bringing it up at a WHATNOT meeting a few months ago looked like it was heading the same way, a “yeah, we’d kinda like to do this, but… meh, see what happens”. Then a few months later Mason Freed of Google decided to try championing it. We’ll see where things go.
Why should the presence of replies to your comment mean that they don't agree with you? Sometimes replies add more context or are simply elaborated me-toos.
I think that's the exact point the parent commenter is trying to make. One person said Google has wanted to get rid of XSLT for years, which someone else responded to saying that it was Mozilla who made this proposal, and then someone else responded with details about Google's history of wanting to get rid of it previously, at which point the question around what part of the second comment been untrue entered the picture. That question doesn't make a ton of sense, because if the reply to the second comment was assumed to be disagreement, the same logic would presumably apply to the second comment itself, so the question "what part is untrue?" would be just as valid to ask about the "disagreement" with the original statement that Google has wanted to get rid of XSLT for years.
Of course, I could be making the same mistake in reading your comment as expressing disagreement with the one you're responding to! If that's not the case, then I'll happily accept my mistake so the chain can hopefully stop here.
(edit: I'm realizing now that this definitely is my own mistake, as I misread which comment this one was replying to. I might need to invest time in finding a new app for reading HN on mobile, since the indentation levels on the one I've been using clearly aren't large enough for my terrible eyesight...)
This is a good comment and there is an answer to your question. I know because I react the same way sometimes. It's about insecurity. They're interpreting it as negative by default either because they've been treated poorly before or because they have low self-esteem. Either way, their state shapes their expectations.
There's a perverse irony to responding like this (besides the fact that no one, whether implicitly or explicitly, said anything like, "That's not true"), since the comment you replied to merely mentioned "Google wanting to rid Chrome of XSLT support", which you indicated was untrue. Which part, exactly?
There are many things I don't love about how tech has evolved, but when I look at a massive blob of XML and a lengthy explanation of "why this is better than just writing code!" I feel a little a bit more accepting of the current state of things.
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.
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.
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.”
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.
If you’re only using XML for AJAX style communication of fragments of data between a model and view, sure, use JSON or whatever. If, on the other hand, you’re encoding a representation of a text and need to mark it up to indicate bibliographic features and textual variation between editions, you need TEI XML. If you want a dataset to be available in a machine-readable format at a particular address and also have that data look good for humans, you want XML. XML is for more than passing messages from a backend to a frontend.
I wasn't meaning to imply that XML is only for backend to frontend communication. I only mentioned they as it seems to be the most common task in web jobs today and is usually what a person does most often when I hear the complaint that XML is pointless and we should just use JSON.
Were you using XSLT 1.0 for native browser support? If so, yeah its pretty damn frustrating both in the APIs and the lack of browser support for basic debugging.
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.
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.
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.
I worked in the music streaming industry, which involves ingesting 10's of millions of XML files. Absolutely do not use XSLT. Schema changes between different versions of DDEX were a nightmare for all the legacy XSLT we had.
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!
XSLT rocks. I have a team who come from business analyst and accounting backgrounds, we manage hundreds of reports for client data to their banks and could never manage it without something simple like XSLT to deal with it all.
You give the employee IntelliJ or some IDE of your choice and a way of uploading the transforms into your application and they'll work away. All the complaints about namespaces and the like that your hear online? Never hear from them, they dont think about it, just stick the declarations up in the top of the file and work away.
Abandoning XML has been one of softwares biggest mistakes.
The ability to use XSLT to convert JSON to HTML may be useful when making extensions for working with web sites that internally use JSON. Converting XML to JSON might also be useful for some things.
However, XSLT would be useful with command-line programs too, and not only in a web browser, anyways. (A standalone implementation might also be made to have the ability to load extensions written in C.)
There are problems with XML and with JSON, as well as with XSLT, but when dealing with XML and JSON formats anyways, XSLT can be helpful. (One problem is that XML does not deal very well with types other than Unicode text (JSON has a few additional types but still not very good). XSLT does add some types, though.)
They also mention RDF, but the standard XML format for RDF is not very good in my opinion (although I think someone did make up a better XML format for RDF, for the help of being used with XSLT better).
Decades ago, I worked on the XCB library (the replacement for Xlib). I replaced the M4 macros used to generate all the X protocol bindings with XML protocol definitions and XSLT to do code generation.
The XML turned out extremely well, and it's still being used today, such as for bindings in several other languages.
Someone rewrote my XSLT in Python, and I cheered them on, because the result was much more readable, not least of which because the fundamentally procedural steps could be written in a procedural language with a good syntax, rather than XSLT's pure-functional language that suffered from being embedded in XML.
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.
XSLT is not a programming language. It's a declarative transform for XML, and when you need such a thing, it is extremely useful.
Let's see:
- Variable scoping https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Function definition and application https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Flow control https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Loops https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
- Module system https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...
Yep, it's a programming language. And not a great one!
nah. its a transform for XML and its super useful when you need it. People such as yourself who claim its not a great programming language are probably not trying to use it for the right thing.
I was using it to transform DocBook XML into LaTeX, based on an existing tool that used xslt code to do just that (https://sourceforge.net/projects/dblatex/). We had to modify the existing xslt code to allow for enhancements to DocBook that accommodated some linguistic structures (like interlinear text). So yes, we were using it for exactly the right thing: transforming XML.
yes, transforming xml. and it was useful. great!
edit: zomg mcswell I see you're the person I was replying to in the first place, to this absurd comment:
"First, who decided that XML was a good format to write a programming language in? Punch cards would have been better"
I mean come on.
On what grounds do you contend that it's not a programming language? There are other declarative programming languages, like Prolog, so I fail to see how the fact that it's a "declarative transform" makes it any less of a programming language.
> And second, trying to debug it was embarrassingly difficult.
I remember that in the past Visual Studio had a pretty decent debugger for XSLT.
Is XSLT enjoying the equivalent of Streisand Effect? Ever since news came out of Google wanting to rid Chrome of XSLT support, there has been a number of XSLT-related news here. I am not complaining, I think XSLT deserves a second life, it hasn't had the scrutiny it deserves, nor its "15 years of fame".
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.
As an aside, I note that MSHTML supported “HTML+TIME” (anyone remember Vizact?).
It wasn't Google. The original proposal came from Mozilla, and apparently all the browser vendors want to be rid of it.
Browser makers trying to kill XSLT is not new: Chrome had intents to deprecate and remove XSLT in 2013 and 2015 (which both failed).
Each time so far, there’s been movement for a while, significant pushback, and the one who was championing removal realises it’s hard, and quietly drops it. Smaug from Mozilla bringing it up at a WHATNOT meeting a few months ago looked like it was heading the same way, a “yeah, we’d kinda like to do this, but… meh, see what happens”. Then a few months later Mason Freed of Google decided to try championing it. We’ll see where things go.
Which part of what I said was false?
Why should the presence of replies to your comment mean that they don't agree with you? Sometimes replies add more context or are simply elaborated me-toos.
I think that's the exact point the parent commenter is trying to make. One person said Google has wanted to get rid of XSLT for years, which someone else responded to saying that it was Mozilla who made this proposal, and then someone else responded with details about Google's history of wanting to get rid of it previously, at which point the question around what part of the second comment been untrue entered the picture. That question doesn't make a ton of sense, because if the reply to the second comment was assumed to be disagreement, the same logic would presumably apply to the second comment itself, so the question "what part is untrue?" would be just as valid to ask about the "disagreement" with the original statement that Google has wanted to get rid of XSLT for years.
Of course, I could be making the same mistake in reading your comment as expressing disagreement with the one you're responding to! If that's not the case, then I'll happily accept my mistake so the chain can hopefully stop here.
(edit: I'm realizing now that this definitely is my own mistake, as I misread which comment this one was replying to. I might need to invest time in finding a new app for reading HN on mobile, since the indentation levels on the one I've been using clearly aren't large enough for my terrible eyesight...)
This is a good comment and there is an answer to your question. I know because I react the same way sometimes. It's about insecurity. They're interpreting it as negative by default either because they've been treated poorly before or because they have low self-esteem. Either way, their state shapes their expectations.
There's a perverse irony to responding like this (besides the fact that no one, whether implicitly or explicitly, said anything like, "That's not true"), since the comment you replied to merely mentioned "Google wanting to rid Chrome of XSLT support", which you indicated was untrue. Which part, exactly?
> came from Mozilla
Maybe they should stop wasting money on pointless, proprietary side tangents before they set out to break standards.
It’s a parallel universe Lisp/Rust as far as HN goes.
[dead]
There are many things I don't love about how tech has evolved, but when I look at a massive blob of XML and a lengthy explanation of "why this is better than just writing code!" I feel a little a bit more accepting of the current state of things.
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.
Hell, you can parse XML and infer complex types! Good luck doing that with JSON though.
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.
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.”
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.
If you’re only using XML for AJAX style communication of fragments of data between a model and view, sure, use JSON or whatever. If, on the other hand, you’re encoding a representation of a text and need to mark it up to indicate bibliographic features and textual variation between editions, you need TEI XML. If you want a dataset to be available in a machine-readable format at a particular address and also have that data look good for humans, you want XML. XML is for more than passing messages from a backend to a frontend.
I wasn't meaning to imply that XML is only for backend to frontend communication. I only mentioned they as it seems to be the most common task in web jobs today and is usually what a person does most often when I hear the complaint that XML is pointless and we should just use JSON.
Agreed. I tried XSLT once. I made an XSLT for RSS. Coding in XSLT really sucked.
Were you using XSLT 1.0 for native browser support? If so, yeah its pretty damn frustrating both in the APIs and the lack of browser support for basic debugging.
LLMs make it much easier. Then you get all the benefits with few of the frustrations
!
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.
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.
If somebody wants to help XSLT 3.0...
This open source Rust implementation needs more help of integrating the full XSLT 3.0 standard into their engine
https://github.com/Paligo/xee
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.
I worked in the music streaming industry, which involves ingesting 10's of millions of XML files. Absolutely do not use XSLT. Schema changes between different versions of DDEX were a nightmare for all the legacy XSLT we had.
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!
XSLT rocks. I have a team who come from business analyst and accounting backgrounds, we manage hundreds of reports for client data to their banks and could never manage it without something simple like XSLT to deal with it all.
You give the employee IntelliJ or some IDE of your choice and a way of uploading the transforms into your application and they'll work away. All the complaints about namespaces and the like that your hear online? Never hear from them, they dont think about it, just stick the declarations up in the top of the file and work away.
Abandoning XML has been one of softwares biggest mistakes.
The ability to use XSLT to convert JSON to HTML may be useful when making extensions for working with web sites that internally use JSON. Converting XML to JSON might also be useful for some things.
However, XSLT would be useful with command-line programs too, and not only in a web browser, anyways. (A standalone implementation might also be made to have the ability to load extensions written in C.)
There are problems with XML and with JSON, as well as with XSLT, but when dealing with XML and JSON formats anyways, XSLT can be helpful. (One problem is that XML does not deal very well with types other than Unicode text (JSON has a few additional types but still not very good). XSLT does add some types, though.)
They also mention RDF, but the standard XML format for RDF is not very good in my opinion (although I think someone did make up a better XML format for RDF, for the help of being used with XSLT better).