Posted by CharlesW 11/1/2025
This would make creating competition easier and reduce attack surface. As a nice side effect, it would become impossible to use canvas or web audio for fingerprinting.
Firstly, it puts a huge burden of non-value-adding work onto developers and the organisations they work for.
Secondly it would lead to even higher frequency and prevalence of people inventing their own half-arsed ways of doing things that used to be in the box. Nobody would think about standard usability affordances, accessibility, etc.
Thirdly, it would simply move the attack surface into an emergent library ecosystem without really solving anything.
Fourthly, it would increase website payloads even further. Developers have historically been awful at using bandwidth efficiently (still a concern in many scenarios due to connectivity limitations and costs), and we don’t need to offer more opportunities for them to demonstrate how terrible and undisciplined they are at it.
Fifthly, not everyone wants or needs (or should!) to learn web assembly in the same way that not everyone wants or needs to learn x86/64 assembly, ARM assembly, C or Rust.
Sixthly, it would lead to a huge amount of retooling and rewriting which, yes, to some extent would happen anyway because, apparently, we all love endless churn masquerading as progress, but it would be considerably worse.
The web would become significantly buggier and more unusable as a result of all of the above.
TLDR: QEMU but much simpler and only WASM need be supported.
Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).
JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. [..]
Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user [paying for that saving on costs by some big company - or having to redo NOW in less efficient way something that still works well so far regardless of decades passed] !
https://news.ycombinator.com/item?id=44994459 - with answering lame questions of a developer not having a clue what is all about.
(Just.. live and let others live too ? Thx.)
Moreover.. Content First - and browser is a secondary thing to existing content (Chrome came after) - not the (double) opposite (primary, for ads n tracking instead)
- isn't Google as a public servant - so part of their job is to fix their bugs - but not in the position to decide to kill someone else existing content or solution - for not displaying ads so easy?
Can be "made with JS" doesn't mean that by chance it would be in any bit better than long proved and still used solution - not a one of many crippled, always changing, excluding imitations of it - for example like that one: https://news.ycombinator.com/item?id=45183624 (no caching, not instant, transparent or othogonal etc.).
With XSLT removed, Chrome can not claim to be a standard internet browser neither.
There is nothing wrong with XSLT - it's just Google not wanting to fix few bugs since decades - but others have to follow, nothing changes.
Actually.. I can't care less about Chrome - if others will not follow neither allow Google to reach such position claiming to be able to dastandardize working and used solutions.
Maybe for a few small things like JSON, I suppose, but not for any of the major standards. And not just as in they implement a superset of the standards - every browser implements a distinct set of each standard that is neither a subset nor a superset.
I'm still not a fan of Chrome nor the effect it has on the web.
But I see less of that money but much better used - to support any of open, independent, not for profit, conforming to standards browsers instead - in not following what a big corporation says and want.
The input has to be XML, but you can get there via YAML, JSON, tree-sitter etc. And the output doesn't have to be XML.
xsltproc is usually easy to install.
Typically, these use XSLT on the backend to transform the content to HTML to be sent to the web browser.
And there's RSS which was mentioned in the previous discussions. Podcasts will typically have HTML renderings of that data, but if you opened the RSS in a web browser you could use XSLT to provide a user-friendly view of the content.
XSLT can also be used to provide fallback rendering for unsupported content, such as converting MathML to HTML for browsers without support. -- Chrome as of 109 supports MathML Core, but doesn't support the content markup (used for more semantic markup of common constructs like N-ary sum, integrals, etc.), so would still need something like XSLT to convert that markup to the presentation markup supported by Chrome.
And XSL is used to validate invoice documents.
And yes, sadly the powers that be decided that this crap needs to be XML. Because why not, why use a modern standard...
Where XSLT shines, and JavaScript currently has no equivalent afaik, is in transforming a tree into another one, rule-based.
The lack of support of XSLT 2.0 in browsers is a major issue, as it includes many solutions to problems absolutely not covered by XSLT 1.0.
[1]: xml2dict/dict2xml is an implementation of exactly this duality.
... for who?
We might see real world usage of these technologies had browser vendors not frozen them out.
And he was also the spec editor, his incentive was to get lucrative contracts from BigTech, not make the world a better place.
Saxon has a free HE version [2] that has the source code available and implements XSLT 2.0 REC, 3.0 REC, and 4.0 ED at the baseline conformance. The paid version implements optional features and vendor-specific extensions [3].
Even though Michael Kay is the editor of the spec, several others are involved in the standardization of XSLT, XPath, and XQuery, including members from BaseX and eXist-db which provide XQuery implementations. And as XPath is a subset of XSLT and XQuery there's a lot of overlap there, and features come from many people, not just Michael Kay.
[1] https://en.wikipedia.org/wiki/XSLT#Processor_implementations