Couldn’t agree with this more.
Every time I create a website, I first create it with only HTML. If it looks right and makes sense, then I will add CSS. If it looks good and works fine, then I will add JS.
JavaScript sucks. I hate using it I hate coding it.
I whitelist js sources on my personal computer.
Only absolutely necessary for function scripts get loaded.
If they ask me to disable the adblocker I blacklist the domain.
I’ve done more than 18 years of dev work. I only hate js. All the other parts of the job are fine. Other languages are fine as well. I’ve had to learn so many. Hell I know cobol right along side ruby.
Js sucks. It sucks to debug. Its frameworks still have issues with basic stuff like many to many relationships.
All the solutions that don’t use or use it sparingly work for years. The ones that rely on the language usually die a firey death by npm/yarn or get deprecated within 6 months.
Js frameworks make php frameworks seems stable efficient and logical by comparison.
Yikes.
Lmao, oh yes, let’s go back to the golden age of every app having all of its logic running on centralized servers, rather being able to easily create cross platform client side distributed applications.
The “no-js” philosophy is fundamentally at odds with a future of distributed, OS agnostic, application development.
It remembers the web when the web was simpler, and ignores that that was the era of dll hell and applications being locked to specific OSes. The modern web is the most successful cross platform development framework by orders of magnitude,it’s all based on open internationally agreed on standards, and it is vastly simplifying and detangling the overall computing environment / platforms that we used to be locked to.
Just use a framework like Nextjs or it’s open source off shoots / clones and get the best of both static pre rendering and dynamic on the fly rendering.
#1 popup and tracker enjoyer over here
I use utilities like unlock origin, a pihole, etc to block trackers and ad network requests without blocking literally all logic that can run on a page, which works great as an interim solution.
And the long term solution to advertising and tracking is legislation, not throwing out a computer’s ability to compute.
Personally I think it’s better if WWW moves beyond HTTP as a protocol
Note there’s a group of users that larger than the group of users without JS (for whatever reason): users of assistive technology. And they don’t even have a choice.
While I’m all for considering the needs of every user… If you get to the point where you’re worrying about no-JS users, I hope you’ve already considered the needs of people with disabilities, whether temporary or permanent.
Edit: oh right, wanted to add: just making a site work without JS doesn’t automatically make it accessible to people with special needs.
No-JS pages that fully comply with WAI ARIA are much better for users of assistive technology than any single page web app can ever hope to be. All the myriad states that an interactive JS page can enter are absolutely never ever properly tested for disabled users, and even after full expensive testing, just a little change in the JS can ruin it all again. While with WAI ARIA you can just quickly assert that the page is compliant with a checker before pushing it to live.
Definitely not. NoJS is not better for accessibility. It’s worse.
You need to set the ARIA states over JS. Believe me, I’ve written an entire component library with this in mind. I thought that NoJS would be better, having a HTML and CSS core and adding on JS after. Then for my second rewrite, I made it JS first and it’s all around better for accessibility. Without JS you’d be leaning into a slew of hacks that just make accessibility suffer. It’s neat to make those NoJS components, but you have to hijack checkbox or radio buttons in ways not intended to work.
The needs of those with disabilities far outweigh the needs of those who want a no script environment.
While with WAI ARIA you can just quickly assert that the page is compliant with a checker before pushing it to live.
Also no. You cannot check accessibility with HTML tags alone. Full stop. You need to check the ARIA tags manually. You need to ensure states are updated. You need to add custom JS to handle key events to ensure your components work as suggested by the ARIA Practices page. Relying on native components is not enough. They get you somewhere there, but you’ll also run into incomplete native components that don’t work as expected (eg: Safari and touch events don’t work the same as Chrome and Firefox).
The sad thing is that accessibility testing is still rather poor. Chrome has the best way to automate testing against the accessibility tree, but it’s still hit or miss at times. It’s worse with Firefox and Safari. You need to doubly confirm with manual testing to ensure the ARIA states are reported correctly. Even with attributes set correctly there’s no guarantee it’ll be handled properly by browsers.
I have a list of bugs still not fixed by browsers but at least have written my workarounds for them and they are required JS to work as expected and have proper accessibility.
Good news is that we were able to stop the Playwright devs from adopting this poor approach of relying on HTML only for ARIA testing and now can take accessibility tree snapshots based on realtime JS values.
Well, I suspected this might be the case - since I have never worked somewhere the functionality is actually end user tested - only worked with some accessibility “experts” for a short while that just made sure the code ticks the right boxes. I somehow hoped the state of the technology rendering the HTML code and the state of WAI ARIA was better, but it seems not to be the case.
