| Your analogy fails. Javascript is designed to be an addon to HTML / CSS. An alternator is not designed to be an addon to a car. (Well, to be pedantic an alternator is an addon, but some means of electrical generation isn't - some means of electrical generation is integral to a (non-diesel) motor) A better analogy might be your car refusing to start because your OnStar subscription expired - and things like that are actually starting to happen. And no, I don't like it there either. Here's the thing with JS: I fail to see what it adds. And yet at the same time I can see rather drastic examples of what it loses. Namely security. I will start enabling JS by default when JS-based exploits stop being a routine thing. However, I doubt that will happen anytime soon. Because, oddly enough, when you have a complex language, and everyone demands every last drop of performance, security suffers. At least assuming dev time is constant. Oh, and enabling JS also enables an absurd amount of tracking. And performance problems. Oh, and website bloat. So those are the downsides. As such, what are the upsides? Give me a justification for why I should enable JS globally. I have yet to see a good reason. And no, badly reimplementing parts of HTML / CSS is not an answer. AJAX? There are some things that are better with AJAX, for certain definitions of better. In which case I enable it for the page / website and go from there. Still not a justification for globally enabling JS. And most of the time I'd prefer proper pages anyways. AJAX tends to break things - URLs actually being uniform resource locators and opening links in new tabs in particular. About the only thing I actually find myself wanting AJAX for is webmail clients, and it's iffy even then. Most other things are, again, bad reimplementations of HTML / CSS. (Case in point: infinite scrolling) And as for your comment about CSS - yes, in fact. Or rather, there are a number of websites that I override the CSS on. And if/when there starts to be a steady stream of exploits for features in CSS, I'll consider blocking those by default. But currently there doesn't seem to be. Largely, I suspect, because CSS parsing isn't Turing-complete (as far as I know at least). (I know that CSS + repeated "dumb" input is Turing-complete, but that's not the same thing.) In parting: I don't mind when disabling JS disables JS-only features. What I mind is when disabling JS means that the things that HTML / CSS are designed for no longer work because devs tried too hard to reinvent the wheel. Case in point: those websites that require JS just to display a static page because they're parsing markdown on the client or some such absurdity, and they don't even display the raw pre-markdowned text if you load it without JS because instead of doing the (relatively) sane thing of putting the text into the HTML and parsing it and replacing it, they store the entire thing as a JS string. I mean, really, if your solution is "make every client that ever visits your static website duplicate the same work (and load in massive libraries to do so, to boot) that you could do easily server-side once", you're asking the wrong question. |
Your analogy fails because you think the original design intent matters, it does not. What matters is how people use things, not how they were intended to be used. His analogy was correct, developers do build their sites with js capabilities assumed and if you remove those abilities you break much of the web today and you know it.