Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should we remove XSLT from the web platform?

github.com

Post reply on HN
Print view View original

11–20 of 99 posts

Re: Should we remove XSLT from the web platform?

#11

Post by 3036e4 »

conductr wrote: post #4
omgtehlion wrote: post #3

Earlier quoted context omitted.

> so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant d…

When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required

Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability.

I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprecated (and a list of things that changed, that might or might not break rendering of old pages). Old saved pages will eventually begin to degrade and some might eventually be unreadable without having to mess with virtual machines to run old browsers.

Re: Should we remove XSLT from the web platform?

#12

Post by cousin_it »

JimDabell wrote: post #2

Some recent discussion on XSLT here: XSLT – Native, zero-config build system for the Web – 27th June 2025 (328 comments): https://news.ycombinator.com/item?id=44393817 The only useful thing I have seen it do in the past couple of decades has been to style Atom/RSS feeds. I haven’t personally used it in 25 years. The complexity and attack surface area isn’t justified by its utility, so it’s hard to make the case for k…

Maybe off topic, but I was really inspired by this article and started thinking about other ways to have "in-browser templating". And then realized that the old function document.write() is actually very convenient for this. Tried to write up the pros and cons here: https://vladimirslepnev.me/write

Amusingly, just like XSLT, document.write is in the process of being deprecated: https://developer.mozilla.org/en-US/docs/Web/API/Document/wr...

Re: Should we remove XSLT from the web platform?

#14

Post by edent »

miki_oomiri wrote: post #5

The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of…

Why shouldn't people be overly emotional? Humans are emotional - and that's a good thing.

This change would make people sad because things they like would stop working.

It would cause them stress because they would have to work hard to fix or replace things.

It would cause them anger because some unaccountable people would be making decisions without considering them.

It would make them afraid that those same people might destroy something else which is useful.

These are all valid and useful emotional responses. Telling someone "if you do this it will make me sad" should be useful feedback.

Web developers aren't Vulcans. We have and use emotions.

Re: Should we remove XSLT from the web platform?

#15

Post by hereonout2 »

bawolff wrote: post #8

I always kind of liked XSLT but it clearly has not caught on.

I used it everyday for the first 5 years of my career, got my first big job off the back of a shorter graduate job that exposed me to it.

It will always have a special heart too.

However, in the way it was used in my roles at least - I found it enforced far too rigid a separation between the data and the presentation.

There were multiple times a backend could not perform some function or transformation of the data, for various and always non technical reasons.

That left it to the xslt developers to figure out a solution, and sometimes due to the limits of the language that involved writing a custom java function / xslt plugin.

Things that were incredibly simple when some sort of scripting language is available in your frontend web app could be incredibly convoluted when all you had was an xslt processor.

Re: Should we remove XSLT from the web platform?

#16

Post by perching_aix »

edent wrote: post #14
miki_oomiri wrote: post #5

The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of…

Why shouldn't people be overly emotional? Humans are emotional - and that's a good thing. This change would make people sad because things they like would stop working. It would cause them stress because they would have to work hard to fix or replace things. It would cause them anger because some unaccountable people would be making decisions without considering them. It would make them afraid that those same people…

> Web developers aren't Vulcans. We have and use emotions.

You might find that the people on their end, too, have and use emotions.

Acknowledging and voicing your emotional and mental position is one thing, that alone doesn't make it overly emotional. What does is being so taken by them, that it ends up trampling on others'.

Re: Should we remove XSLT from the web platform?

#17

Post by comex »

conductr wrote: post #4
omgtehlion wrote: post #3

Earlier quoted context omitted.

> so it’s hard to make the case for keeping it. How about “not breaking stuff” which can not be upgraded? Like old sites/services without active maintainers but still useful. Or hardware appliances that still work, but will not get firmware update ever. Let alone rss feeds, brought up multiple times in the linked thread. Looks like builtin polyfill (similar to pdfjs in FF) would do. But google seems to be reluctant d…

When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required

Why can’t things remain backwards compatible forever? In the 35 years that the Web has existed, browsers have come pretty damn close to meeting that standard. The one huge exception is the removal of plugin support around 2015, and the concomitant death of Flash and Java applets. There were also some major browser-specific APIs that got killed off, like ActiveX and NaCl. But when it comes to standardized, browser-native functionality… very little has ever been removed. I would prefer it if I could say the same thing in another 35 years.

Re: Should we remove XSLT from the web platform?

#18

Post by haburka »

edent wrote: post #14
miki_oomiri wrote: post #5

The quality of the github comments: accusing developers of being dictators, being overly emotionally, the hate towards people who actually made the web happen (Smaug, Anne, Emilo, etc…), the "why not just…" or "hire more people" remarks... For a browser developer, this is depressing. I've worked on Gecko for 10+ years, and we were constantly called names for absolutely any change we would do. Insulted and accused of…

Why shouldn't people be overly emotional? Humans are emotional - and that's a good thing. This change would make people sad because things they like would stop working. It would cause them stress because they would have to work hard to fix or replace things. It would cause them anger because some unaccountable people would be making decisions without considering them. It would make them afraid that those same people…

It’s ok to have emotions, even as an adult, we all have feelings. However, it’s important to be kind to other humans and to treat humans with respect. Even on the internet, even when people are proposing removing features from a browser. Now it can be difficult to voice opposition without coming off as rude but its definitely an important skill for a professional to have.

I think this is especially true on GitHub where people are using their real professional identities. I’m honestly shocked that anyone can just comment on these proposals given how toxic it gets. Imagine if this is your day to day work environment - you’re trying to improve the web, which is already a tremendously difficult thing while all of these keyboard warriors are insulting you and your efforts. I wouldn’t want to wish that on anyone.

Re: Should we remove XSLT from the web platform?

#19

Post by globular-toast »

Isn't it a shame that we can only have one program installed on our computers.

Imagine (if you can!) being able to have two programs, one (program A) that supports JS and all that shite, and another (program B) that supports XSLT and all that shite. If you're still with me imagine that program A could just call program B when it detects stuff that it doesn't support and vice versa.

I know, I know, a measly 16 core CPU with 32Gi of memory is not going to be capable of such feats, but one can dream...

Re: Should we remove XSLT from the web platform?

#20

Post by shiomiru »

3036e4 wrote: post #11
conductr wrote: post #4

Earlier quoted context omitted.

When’s a reasonable time to pull the plug on out of fashion legacy stuff? Things can’t always remain backwards compatible forever. I think the places this is still in use can build contingencies where required

Things can remain backwards compatible forever. That is what any good standard does. Web standards and much else in software is sadly a complete mess where too few care about all the downsides of instability. I am a bit worried because for many years I used plugins like SinglePage to save web pages as HTML. That is not exactly future-safe since every relase of Chromium or Firefox has a list of things that were deprec…

> Things can remain backwards compatible forever.

This is exactly the attitude that has left us with only three complete extant implementations of the web, two of which are controlled by an ad company.

Indeed, to me it seems that at some point, you either have to

a) freeze the standard

b) drop old stuff

c) accept that there is no standard

and with the web as a whole, we are firmly headed towards option c). So I find the short-sightedness of all people pushing back against this proposal unfortunate.

(Also note that dropping a barely-used Turing-complete language from the web is not comparable to removing deprecated HTML elements. The latter typically requires just a few lines of CSS in the UA style sheet, so I doubt anybody is considering doing that.)

Post reply on HN