5 ms·

To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't c

To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all). I think being able to do client-side templating without JS is an important feature and I hope that since browser vendors are removing XSLT they will add some kind of client-side templating to replace it.

Aurornis 11mo ago
> I block JS The percentage of visitors who block JS is extremely small. Many of those visits are actually bots and scrapers that don’t interpret JS. Of the real users who block JS, most of them will enable JS for any website they actually want to visit if it’s necessary. What I’m trying to say is that making any product decision for the extremely small (but vocal) minority of users who block JS is not a good product choice. I’m sorry it doesn’t work for your use case, but having the entire browser ecosystem cater to JS-blocking legitimate users wouldn’t make any sense.
- davisr 11mo ago
  I block JS, too. And so does about 1-2% of all Web users. JavaScript should NOT be REQUIRED to view a website. It makes web browsing more insecure and less private, makes page load times slower, and wastes energy.
  - dpark 11mo ago
    > And so does about 1-2% of all Web users. To put that in context, about 6 percent of US homes have no internet access at all. The “I turn off JS” crowd is at least 3x smaller than the crowd with no access at all. The JS ship sailed years ago. You can turn it off but a bunch of things simply will not work and no amount of insisting that it would not be required will change that.
    - kstrauser 11mo ago
      Without saying whether I think that's a good or bad thing, as a practical matter, I 100% agree. Approximately no major websites spend any effort whatsoever supporting non-JS browsers today. They probably put that in the class of text only browsers, or people who override all CSS: "sure, visitors can do that, but if they've altered their browser's behavior then what happens afterward is on them." And frankly, from an economic POV, I can't blame them. Imagine a company who write a React-based website. (And again, I'm not weighing in on the goodness or badness of that.) Depending on how they implemented it, supporting a non-JS version may literally require a second, parallel version of the site. And for what, to cater to 1-2% of users? "Hey boss, can we triple our budget to serve two versions of the site, kept in lockstep and feature identical so that visitors don't scream at us, to pick up an extra 1% or 2% of users, who by definition are very finicky?" Yeah, that's not happening. I've launched dozens of websites over the years, all of them using SSR (or HTML templates as we called them back in the day). I've personally never written a JavaScript-native website. I'm not saying the above because I built a career on writing JS or something. And despite that, I completely understand why devs might refuse to support non-JS browsers. It's a lot of extra work, it means they can't use the "modern" (React launched in 2013) tools they're use to, and all without any compelling financial benefit.
    - davisr 11mo ago
      I'm hearing you say, "don't waste your breath because change is not possible." And there you have your self-fulfilling prophecy. To quote someone who lived before me: don't accept the things you cannot change. Change the things you cannot accept. And the no-JS ship has not sailed. Government websites require accessibility, and at least in the UK, do not rely on JS.
      - dpark 11mo ago
        Then you misheard me. I’m not saying change is not possible. I’m saying the change you propose is misguided. I do not believe the entire world should abandon JS to accommodate your unusual preferences nor should everyone be obliged to build two versions of their site, one for the masses and one for those with JS turned off. Yes, JS is overused. But JS also brings significant real value to the web. JS is what has allowed websites to replace desktop apps in many cases.
  - stronglikedan 11mo ago
    The point of the poster you're responding to is that sites are built JS-first for 98-99% of users, and it takes extra work to make them compatible with "JavaScript should NOT be REQUIRED to view a website", and no one is going to bother doing that work for 1-2% of users.
    - davisr 11mo ago
      Yeah... or...... maybe they should just build websites the proper way the first time around, returning plain HTML, perhaps with some JS extras. Any user-entered input needs to be validated again on the backend anyway, so client-side JS is often a waste.
      - imtringued 11mo ago
        This falls apart the moment you need to add rows to a table or show and hide things in response to values selected in a dropdown. Even the lightest JS app centered around a big form is going to become a huge pain in the ass for literally no benefit. In a company of 100 people, that <0.5% of people who disable JS could literally be one guy, or no one at all.
        davisr 11mo ago
        You can use CSS for interactive-esque things like that. Use JS for all I care, just don't make it mandatory. You /could/ refresh the page with new values. You /could/ paginate your flow. You won't, because you'd rather spend 50 hours getting your JS to work right, than 5 hours writing some PHP. Pity.
        cweagans 11mo ago
        I _could_ also just write API endpoints and handle client-side interaction however I want. If your preferences are incompatible with mine, that's a tradeoff I'm choosing to make. I am doing the work, you see, and I can choose how I want to do it. You ostensibly run some flavor of Linux. Do you also complain that macOS apps don't run on your machine? It seems to me like a similar argument: somebody has developed an application in some particular way, but your choices have resulted in that application not running on your machine. Your choices are not necessarily _wrong_, but they are of very little consequence to somebody who has developed an application with a particular environment/runtime in mind. Why should they have to make significant architectural changes to their application to support your non-standard choices?
  - zzo38computer 11mo ago
    In addition to those things, JavaScripts can also cause some things to not work properly even though they would work without JavaScripts.
  - samdoesnothing 11mo ago
    I make Javascript mandatory to use my sites regardless of if it's necessary.
  - imtringued 11mo ago
    Blocking first party Javascript is a form of lunacy that is so illogical I can only shake my head. Let's say the site runs XSLT in Javascript. Now what? There's nothing that can be done and yet you would ask for further accommodation. Here is why this is abusive: You can always restrict the subset of the web platform you demand to a subset that is arbitrarily difficult or even impossible to support. No matter how much accommodation is granted, it will be all for naught, because some guy out there goes even further with blocking things and starts blocking CSS. Next thing you know there's a guy who blocks HTML and you're expected to render out your website as a SVG with clickable links.
- tptacek 11mo ago
  Of note here is that the segment we're talking about is actually an intersection of two very small cohorts; the first, as you note, are people who don't own a television errr disable Javascript, and the second is sites that actually rely on XSLT, of which there are vanishingly few.
magicalist 11mo ago
> I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all) Recent XSLT parser exploits were literally the reason this whole push to remove it was started, so this change will specifically be helping people in your shoes.
- NL807 11mo ago
  So it's a parser implementation problem, not XSLT per se.
neilk 11mo ago
XSLT is being exploited right now for security vulnerabilities, and there is no solution on the horizon. The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tomfoolery, and from the beginning there were loopholes to introduce unsafe code. As they say, security is not a product, it’s a process. The process we have for existing browser technologies is better. That process is better because more people use it. But even if we were to try to consider the technologies in isolation, and imagine a timeline where things were different? I doubt whether XML+XSLT is the superior platform for security. If it had won, we’d just have a different nightmare of intermingled content and processing. Maybe more stuff being done client-side. I expect that browser and OS manufacturers would be warping content to insert their own ads.
- array_key_first 11mo ago
  > The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. Yes, they also have much more vulnerabilities, because browsers are JIT compiling JS to w+x memory pages. And JS continues to get more complex with time. This is just fundamentally not the case with XSLT. We're comparing a few XSLT vulnerabilities to hundreds of JIT compiler exploits.
  - lifthrasiir 11mo ago
    While JIT exploits represent a large share of vulnerabilities in JS engines, there are enough other classes of vulnerabilities that simply turning JIT off is not sufficient. (The same goes for simply turning JS off, the Web browser internal is complex enough even without JS.)
    - array_key_first 11mo ago
      Turning off the JIT eliminates an entire class of vulnerabilities just by nature of how the JIT works. Ironically, JIT JS is much more susceptible to buffer overflow exploits than even the C code that backs XSLT - because the C code doesn't use w+x memory pages!
SkiFire13 11mo ago
I feel like there's a bias here due to XSLT being negletted and hence not receiving the same powers as JS. If it did get more development in the browser I'm pretty sure it would get the same APIs that we hate JS for, and since it's already Turing complete chances are people will find ways to misuse it and bloat websites.

Aurornis 11mo ago

> I block JS The percentage of visitors who block JS is extremely small. Many of those visits are actually bots and scrapers that don’t interpret JS. Of the real users who block JS, most of them will enable JS for any website they actually want to visit if it’s necessary. What I’m trying to say is that making any product decision for the extremely small (but vocal) minority of users who block JS is not a good product choice. I’m sorry it doesn’t work for your use case, but having the entire browser ecosystem cater to JS-blocking legitimate users wouldn’t make any sense.

davisr 11mo ago
I block JS, too. And so does about 1-2% of all Web users. JavaScript should NOT be REQUIRED to view a website. It makes web browsing more insecure and less private, makes page load times slower, and wastes energy.
- dpark 11mo ago
  > And so does about 1-2% of all Web users. To put that in context, about 6 percent of US homes have no internet access at all. The “I turn off JS” crowd is at least 3x smaller than the crowd with no access at all. The JS ship sailed years ago. You can turn it off but a bunch of things simply will not work and no amount of insisting that it would not be required will change that.
  - kstrauser 11mo ago
    Without saying whether I think that's a good or bad thing, as a practical matter, I 100% agree. Approximately no major websites spend any effort whatsoever supporting non-JS browsers today. They probably put that in the class of text only browsers, or people who override all CSS: "sure, visitors can do that, but if they've altered their browser's behavior then what happens afterward is on them." And frankly, from an economic POV, I can't blame them. Imagine a company who write a React-based website. (And again, I'm not weighing in on the goodness or badness of that.) Depending on how they implemented it, supporting a non-JS version may literally require a second, parallel version of the site. And for what, to cater to 1-2% of users? "Hey boss, can we triple our budget to serve two versions of the site, kept in lockstep and feature identical so that visitors don't scream at us, to pick up an extra 1% or 2% of users, who by definition are very finicky?" Yeah, that's not happening. I've launched dozens of websites over the years, all of them using SSR (or HTML templates as we called them back in the day). I've personally never written a JavaScript-native website. I'm not saying the above because I built a career on writing JS or something. And despite that, I completely understand why devs might refuse to support non-JS browsers. It's a lot of extra work, it means they can't use the "modern" (React launched in 2013) tools they're use to, and all without any compelling financial benefit.
  - davisr 11mo ago
    I'm hearing you say, "don't waste your breath because change is not possible." And there you have your self-fulfilling prophecy. To quote someone who lived before me: don't accept the things you cannot change. Change the things you cannot accept. And the no-JS ship has not sailed. Government websites require accessibility, and at least in the UK, do not rely on JS.
    - dpark 11mo ago
      Then you misheard me. I’m not saying change is not possible. I’m saying the change you propose is misguided. I do not believe the entire world should abandon JS to accommodate your unusual preferences nor should everyone be obliged to build two versions of their site, one for the masses and one for those with JS turned off. Yes, JS is overused. But JS also brings significant real value to the web. JS is what has allowed websites to replace desktop apps in many cases.
- stronglikedan 11mo ago
  The point of the poster you're responding to is that sites are built JS-first for 98-99% of users, and it takes extra work to make them compatible with "JavaScript should NOT be REQUIRED to view a website", and no one is going to bother doing that work for 1-2% of users.
  - davisr 11mo ago
    Yeah... or...... maybe they should just build websites the proper way the first time around, returning plain HTML, perhaps with some JS extras. Any user-entered input needs to be validated again on the backend anyway, so client-side JS is often a waste.
    - imtringued 11mo ago
      This falls apart the moment you need to add rows to a table or show and hide things in response to values selected in a dropdown. Even the lightest JS app centered around a big form is going to become a huge pain in the ass for literally no benefit. In a company of 100 people, that <0.5% of people who disable JS could literally be one guy, or no one at all.
      - davisr 11mo ago
        You can use CSS for interactive-esque things like that. Use JS for all I care, just don't make it mandatory. You /could/ refresh the page with new values. You /could/ paginate your flow. You won't, because you'd rather spend 50 hours getting your JS to work right, than 5 hours writing some PHP. Pity.
        cweagans 11mo ago
        I _could_ also just write API endpoints and handle client-side interaction however I want. If your preferences are incompatible with mine, that's a tradeoff I'm choosing to make. I am doing the work, you see, and I can choose how I want to do it. You ostensibly run some flavor of Linux. Do you also complain that macOS apps don't run on your machine? It seems to me like a similar argument: somebody has developed an application in some particular way, but your choices have resulted in that application not running on your machine. Your choices are not necessarily _wrong_, but they are of very little consequence to somebody who has developed an application with a particular environment/runtime in mind. Why should they have to make significant architectural changes to their application to support your non-standard choices?
- zzo38computer 11mo ago
  In addition to those things, JavaScripts can also cause some things to not work properly even though they would work without JavaScripts.
- samdoesnothing 11mo ago
  I make Javascript mandatory to use my sites regardless of if it's necessary.
- imtringued 11mo ago
  Blocking first party Javascript is a form of lunacy that is so illogical I can only shake my head. Let's say the site runs XSLT in Javascript. Now what? There's nothing that can be done and yet you would ask for further accommodation. Here is why this is abusive: You can always restrict the subset of the web platform you demand to a subset that is arbitrarily difficult or even impossible to support. No matter how much accommodation is granted, it will be all for naught, because some guy out there goes even further with blocking things and starts blocking CSS. Next thing you know there's a guy who blocks HTML and you're expected to render out your website as a SVG with clickable links.
tptacek 11mo ago
Of note here is that the segment we're talking about is actually an intersection of two very small cohorts; the first, as you note, are people who don't own a television errr disable Javascript, and the second is sites that actually rely on XSLT, of which there are vanishingly few.

magicalist 11mo ago

> I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all) Recent XSLT parser exploits were literally the reason this whole push to remove it was started, so this change will specifically be helping people in your shoes.

NL807 11mo ago
So it's a parser implementation problem, not XSLT per se.

neilk 11mo ago

XSLT is being exploited right now for security vulnerabilities, and there is no solution on the horizon. The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tomfoolery, and from the beginning there were loopholes to introduce unsafe code. As they say, security is not a product, it’s a process. The process we have for existing browser technologies is better. That process is better because more people use it. But even if we were to try to consider the technologies in isolation, and imagine a timeline where things were different? I doubt whether XML+XSLT is the superior platform for security. If it had won, we’d just have a different nightmare of intermingled content and processing. Maybe more stuff being done client-side. I expect that browser and OS manufacturers would be warping content to insert their own ads.

array_key_first 11mo ago
> The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. Yes, they also have much more vulnerabilities, because browsers are JIT compiling JS to w+x memory pages. And JS continues to get more complex with time. This is just fundamentally not the case with XSLT. We're comparing a few XSLT vulnerabilities to hundreds of JIT compiler exploits.
- lifthrasiir 11mo ago
  While JIT exploits represent a large share of vulnerabilities in JS engines, there are enough other classes of vulnerabilities that simply turning JIT off is not sufficient. (The same goes for simply turning JS off, the Web browser internal is complex enough even without JS.)
  - array_key_first 11mo ago
    Turning off the JIT eliminates an entire class of vulnerabilities just by nature of how the JIT works. Ironically, JIT JS is much more susceptible to buffer overflow exploits than even the C code that backs XSLT - because the C code doesn't use w+x memory pages!

SkiFire13 11mo ago

I feel like there's a bias here due to XSLT being negletted and hence not receiving the same powers as JS. If it did get more development in the browser I'm pretty sure it would get the same APIs that we hate JS for, and since it's already Turing complete chances are people will find ways to misuse it and bloat websites.