[righthand]

> Sometimes features are removed because they are costly to maintain or security problems or both.

But the features and tech doesn’t have security problems. The library implementation does. This is exactly the kind of bad faith argument I’m talking about. Please just for one second try making an argument pro-XSLT and then try to compare the two mind sets about technology here.

There is no negative trade off by maintaining XSLT other than not being lazy developers. I have no empathy for people who hide behind billion dollar corporations and do their bidding. This is not some sort of critical situation, this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.

[dpark]

> There is no negative trade off by maintaining XSLT other than not being lazy developers.

Only because it’s not your money or time being traded. Yes, if we pretend that engineering effort is free then there’s no reason Google couldn’t just rewrite this entire library in Rust or whatever. But if that were true you would just rewrite the library yourself and send the pull request to Chromium.

In the real world where engineering costs time and money, every decision is a trade off. Someone rewriting libxslt to be secure is someone who’s not implementing other features and who’s not fixing other bugs on the backlog.

Resources allocated to Chromium are finite and while sure, Google could hire 2 more engineers to do this, in reality those 2 new engineers could and would be assigned to higher priority work.

> this is a Google engineer doing things because it’s easier, not “right” or “the difficult choice”.

You keep blaming Google specifically. All of the major browsers are planning to drop this though. They all agree this is the right trade off.

[righthand]

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.

[shadowgovt]

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.

[righthand]

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.

[shadowgovt]

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.

[dpark]

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.

Better now?

[shadowgovt]

There's a lot of people saying "All we need to do is maintain libxslt" and a distinct lack of people actually stepping up to maintain libxslt.

I, for one, won't. Not for the purpose of keeping it in the browser. There are just too many other ways to do what it does for me to want that (and that's before we get into conversations about whether I want to be working with XML in the first place on the input side).

> not being lazy developers

Laziness is one of the three great virtues of programming. Every second not spent maintaining libxslt is a second we can spend on something more people care about.

It's a rule for writers, but it applies to software architecture also: kill your darlings.

[righthand]

Sure. But since this announcement I’ve been planning ways to support xslt. Here are the projects I’m considering:

- iced-ui browser with xslt + servo

- contribute to xslt xrust project

- investigate sandboxing xslt in firefox and implementing xrust

- same as the previous but for Chrome

- have an llm generate 1000s of static websites built in xslt and deploy them across the internet

- promote and contribute to the recent Show HN post of an xslt framework

I figure if I can generate enough effort to spam the web with xslt sites then they can’t remove it. Ultimately the first goal is to delay the removal from Chrome. This will delay the removal in other browsers. I don’t care if it’s ineffective. It’s better than doing nothing.

So you can take your lazy tenants of software engineering and your “hyuck Google knows best” eslewhere.

[shadowgovt]

These are all great ideas and I support you pursuing what you are passionate about.

[righthand]

No you don’t because my passions are for a open technically varied unbroken web and you’ve spent the entire time trying to paint me as crazy for wanting any of that just because not all technology is equally popular or profitable for Google.

[shadowgovt]

With respect: I've never called you crazy, nor did I imply it, nor did I mean to imply it.

I think your cost / benefit analysis on maintaining a native in-browser implementation of an old, niche declarative transformation language for a hard-to-read data format that hasn't been the dominant model of sending data to browser clients for at least fifteen years is flawed, but it's not crazy. Reasonable people can certainly put their priorities in different places, and I respect our priorities don't align on this topic and you have a right to your opinion.