I'm not convinced by the reasons put forth in the article
Your website should work without JavaScript (2021)
91–100 of 159 posts
Re: Your website should work without JavaScript (2021)
#92I used to think this. I even used uMatrix (RIP) to disable all JS. After a while though, it simply wasn't worth it. You'll have a vocal minority on HN of JS disablers, but the truth is most people don't know or care about JavaScript, much less want to disable it. So, it's really not worth catering to this 0.2% or even 1% of people as the article cites. There are just too many interesting things JS can do. I've been p…
I agree. Javascript can do cool stuff. When the author said:
> I'd prefer to write js all day — but finding html and css only solutions has made me a better developer.
> It's forced me to find creative ways of solving problems — and to learn new html and css features.
...it made me think about how you can often do cool thing by taking advantage of some browser functionality, then you look it up on caniuse.com and it's only available on 75% of browsers. Much worse than using a few lines of JS that can't be used by 1% of users.
Re: Your website should work without JavaScript (2021)
#93Earlier quoted context omitted.
Flutter web is one of them. It displays on a canvas element. In the future with WASM, I expect the same thing, a Rust web app that also displays on a canvas for example.
How are you going to address accessibility when rendering everything on a canvas element? What are search engines going to scrape?
Flutter builds a parallel accessibility tree in the DOM that screen readers and search engines scrape. It's kinda cool, you don't have to rely on HTML, CSS and JS as the application layer, use something else like WASM for that, but for the document layer, use HTML. In a way, it's like the original purpose of HTML is preserved, as I see many people on HN complain about how the DOM shouldn't be used for applications and should only be used for documents.
Re: Your website should work without JavaScript (2021)
#94I used to think this. I even used uMatrix (RIP) to disable all JS. After a while though, it simply wasn't worth it. You'll have a vocal minority on HN of JS disablers, but the truth is most people don't know or care about JavaScript, much less want to disable it. So, it's really not worth catering to this 0.2% or even 1% of people as the article cites. There are just too many interesting things JS can do. I've been p…
[deleted]
Re: Your website should work without JavaScript (2021)
#95Quoted post unavailable.
> a lot better than having your site break altogether.
that's a humble baseline, isn't it?
Re: Your website should work without JavaScript (2021)
#96> Building everything you can without js will make your site:
an immediately readable text rather than a program that tries to generate one.
Re: Your website should work without JavaScript (2021)
#97I used to think this. I even used uMatrix (RIP) to disable all JS. After a while though, it simply wasn't worth it. You'll have a vocal minority on HN of JS disablers, but the truth is most people don't know or care about JavaScript, much less want to disable it. So, it's really not worth catering to this 0.2% or even 1% of people as the article cites. There are just too many interesting things JS can do. I've been p…
I'm not going to do that because it's effectively double the work for 1% of the users.
This implies that if you only did the CSS version you'd do the same amount of work as the JS version but it would work for everyone. Why wouldn't you do that? Doing only the JS version means you spend the same engineering effort but it doesn't work for as many people. Choosing to do that when you have a choice makes absolutely no sense.
Re: Your website should work without JavaScript (2021)
#98Re: Your website should work without JavaScript (2021)
#99The real pertinent reason to regulate and to get noscript/basic (x)html web portals (at least on "critical" online services) is that "javascript" requires a grotesquely and absurdely massive and complex web engine, including its SDK.
The only web engines today are blink/geeko, financed by google(vanguard/blackrock), and webkit financed by apple(vanguard/blackrock). They are all written using c++ which has also a grotesquely and absurdely massive and complex syntax, and better not have a look at the compilers... aka double the pain.
In other words: "javascript" = don't have "big tech" controlled software? no web for you!
hard truth: bazillions of online services can work perfectly without a "javacript"-able web engine (javascript alone is some work but several orders of magnitude less), namely basic (x)html forms can do wonders... and actually they were!! But web dev tantrums and planned obsolescence got involved.
The only way out of it is very strong regulation, and I am personally seeing lawyers to seek noscript/basic (x)html interoperability on "critical online services".
Re: Your website should work without JavaScript (2021)
#100This proved tricky for me because of Core Web Vitals. I made ptable.com work without JS, but I still show "dead" interactive components (the properties area above) because expanding it when JavaScript arrives would destroy my Cumulative Layout Shift score.
give everything that is supposed to be js-only a class called js-only (or whatever) and then just do: .js-only { display:none !important; } this won't work on failed script loads, only on actually disabled javascript, though
A .no-js class is sometimes handy too, instead of or in addition to .js-only.
I don't like using to detect absence of JS, because browsers that are blocking JS (e.g. whitelists), or even blocking some JS and allowing others to load (e.g. inline vs same-domain vs cross-domain vs tracking-blockers), haven't actually disabled JS, and won't necessarily render even if the JS won't load.
But there are similar ways to achieve the same thing which don't suffer from this problem. Unfortunately to cover all cases they are complicated, using combinations of inline , , document.write, similar lines in externally loaded scripts which only run if those are loaded, and DOMContentLoaded to do the right thing if a synchronous did not load after all.
Once it's done it works, but it's not trivial to work through all the cases.