alt Hacker NewsI saw it get used a lot.
The "we tried, it failed" story would be a lot more interesting in its bland boring shitty conservative dismissal rejection if the browsers had ever tried to support it. XSLT shipped 1.0 in 1999 and the browsers afaik never once ever did any further work, never bothered on the 2.0 (2007, incredibly better), 3.0 (2017), or new 4.0 (upcoming). Devs had to deal with the pretty jank early version, which changed a lot for 2.0! Massively! For massive betterment.
It's so so cheap and easy to discard and downput. I recommend to those desiring the path of the engineer the builder to be more sensitive. To tune in to what is good, what aspects did work. Look for value. The people in this world need those instincts, to look and assess and collect. The story of why things maybe don't work is the contrapositive failure, the same post hoc ergo propter hoc, but for the failure case. It's wrong, or at least, it usually misses the realer stories. It's a bad analysis filter.
This refusal to ever see the maybe, better, possibly rejects your ability to see and tune for more. Progress on, stop rejecting. Get good. Find good. Look for the good. Bring out the good. Or if not, consider the perhaps. If nothing else, more neutrally: let not you tie your wagon every time to the current of what is! (Another world is possible.)
Ok, well, in good humor I will engage with the ideas of xslt in the browser now.
I see the appeal of being declarative about transforming your data like this, but I don’t think it works out. Simple cases are ok, but then either (1) when things get more demanding your users hit a wall and have to rewrite in some other environment (2) you have to add a lot of complexity and typical programming language flow control constructs, which are an awkward fit, or maybe (3) you provide some kind of "unsafe" trap door to a more traditional environment. XSLT mostly went with 2, and the result is that you get a programming language that is very un-ergonomic for anything other than simplest cases. Maybe I'm overly sensitive to this because there are non-xml, non-xslt cases where I have committed to paths like this and have spent more brainpower than the problems merited on trying to do it "right", where right was kind of arbitrary. It can be an addictive brainteaser!
Second, there's just not much reason for it to be in the browser. XML served on a site is very likely to be view on the data, not the native form of the data on the backend. It's much more straightforward to have whatever transformations you need to do start from the native form of the data than to stack the transformations over xml. And if XSLT is what's convenient? Great! Do it on the back end. In 1999 that didn't seem like such an easy decision.