Surprise, there’s already an effort to write xml related libraries in Rust: xrust library for one.
It doesn’t have to be this pearl gripping bitching and moaning about budgets and practicality. That’s just what Google wants you to believe.
No all of the major browsers weren’t planning to drop this. It literally only started happening because of Google. And Google is essentially forcing the hand. Again this is bad faith argument. I will not concede on my thoughts on this unnecessary destruction of XSLT in the browser while other technologies get a pass.
I don't see how it can be reasonably asserted that this is "destruction of XSLT in the browser" when there are multiple XSLT conversion engines available in JavaScript.
Because when you convert xslt to javascript it’s not xslt is it? It’s javascript pretending to xslt. Furthermore if you restrict rendering xslt to javascript then you lose all the performance benefits of xslt at the engine level.
Also if I’m going to be using Javascript why would I then reach for xslt instead of the other 8000 templating libraries.
All your “its fine to remove it” arguments only work if you ignore all the reasons it’s not fine to remove it. That’s awfully convenient.
You'd be replacing the native-implemented XSLT engine in the browser with a JavScript-implemented XSLT engine living in the JavaScript sandbox, not replacing XSLT with JavaScript.
There's a theorem with Turing's name on it that clarifies why that's equivalent.
> if you restrict rendering xslt to javascript then you lose all the performance benefits of xslt at the engine level.
Nowadays, I'd have to benchmark before just assuming the native implementation is faster. Especially if one of the issues is libxslt is under-maintained. JS is quite fast these days (and the polyfill investigated in the OP is wasm, not even JS). This problem can also be solved by moving the rendering server-side, in which case your ceiling for speed is much higher (and you're not spending your client's CPU on finishing the rendering of your page; added bonus in this era of mobile, battery-constrained devices).
> Also if I’m going to be using Javascript why would I then reach for xslt instead of the other 8000 templating libraries.
Great point. Why do we have this one arbitrary meta-language for declarative transformation of one datatype that's "blessed" with a native implementation? That's an odd corner-case, isn't it. We should probably simplify by putting it on-par with other solutions for that problem.
Google isn’t forcing anyone’s hand here. They are removing functionality. Everyone else could just not do that and maintain compatibility if they believed it was valuable to do so.
I don’t know why you have a chip on your shoulder for Google but sure. Yes, Google is clearly doing this purely because they are evil and removing this little-used tech is the key to cementing their stranglehold on the internet. Yes, Google is strong-arming poor Apple and Mozilla into this. Yes, everyone who disagrees with you is both a complete moron and a “daddy Google” fanboy.
It doesn’t have to be this pearl gripping bitching and moaning about budgets and practicality. That’s just what Google wants you to believe.
No all of the major browsers weren’t planning to drop this. It literally only started happening because of Google. And Google is essentially forcing the hand. Again this is bad faith argument. I will not concede on my thoughts on this unnecessary destruction of XSLT in the browser while other technologies get a pass.