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.