Maybe they should stop wasting money on pointless, proprietary side tangents before they set out to break standards.
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.
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...)
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.
This open source Rust implementation needs more help of integrating the full XSLT 3.0 standard into their engine
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.)
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 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.
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.
I remember that in the past Visual Studio had a pretty decent debugger for XSLT.
- 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!
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.
At any rate, there's absolutely no reason for a command in any programming language to require open and close XML tags: it's a waste of space, and just gets in the way of understanding the program,. If you need to close a command, there are things like {}, semicolons, parens (LISP), exdenting (Python), or even--yes--the 80th column in a punch card.
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).
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.
roadside_picnic•5mo ago
greggman65•5mo ago
_heimdall•5mo ago
vgr-land•5mo ago
xyz_opinion•5mo ago
wrs•5mo ago
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.
hackrmn•5mo ago
jact•5mo ago
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.”
_heimdall•5mo ago
Telemakhos•5mo ago
_heimdall•5mo ago
lenkite•5mo ago
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.
arcfour•5mo ago