To build this feature for the tiny fraction of non-JS users, you're looking at duplicating all of this functionality on the server. This greatly increases dev time and complexity of the codebase. It means moving from an entirely API-driven platform to one where your server needs to understand the app logic as well.
Like it or hate it, Javascript is a web standard. You know that websites will break if you disable CSS -- the expectation should be the same for disabling Javascript.
Website layouts need to be made linear (single column) for display on mobile and the content order usually reflects that anyway. They also need to make sense when using screen readers.
Disabling CSS and checking the result gives you a quick sanity test that the content order makes sense and that the markup is used somewhat correctly. It won't be pretty, but it should be useable.
When I go to a blog post linked from HN and see a white empty page I will just move on.
Code execution is part of the web, it's here to stay, the number of sites that support non-JS experiences will continue to dwindle.
You're not some special snowflake. Other people make real decisions based on cost/value models, and you cost way more than you're worth.
As far as I'm concerned, if it's not readable without javascript then you've got nothing intelligent to say anyway.
Great! Leave please. I have no desire to interact with folks who approach the world in that manner.
You are more than welcome to disable JS, but the number of web developers that I've met that actually care about a non-JS user experience is next to zero.
Of course they can. The <form> action submits via POST to an endpoint that disambiguates the selected action, and forwards inside the server side to the appropriate endpoint. Shouldn't be hard with a competent framework.
Then, when JS is enabled, you override the click action on the action buttons, so that the <form> action never gets used.
You're asking web developers to come up with two methods to accomplish the same goal, which doubles the number of ways the app can break. It's totally unrealistic for any moderately complex web application.
I think it depends on the user demographic. If you're actively developing a service that you hope to be used even in the most deprived areas with outdated equipment and poor connections, then it may be worth it. For example, outreach programs, charities, and emergency services.
If you're developing something that is more or less a needless, but useful, product -- your demographic is more than likely the upper 30% of earners in the world... yeah, probably not worth your time to develop for that 1% who won't be using JS (or have the capacity for only older versions).
For example, imagine a forum where clicking the "edit post" button turns your post into a <textarea> editor and saves with AJAX so that you can continue scrolling once you make your edit.
To build the JS-free version, you typically need a separate endpoint, a new template, a redirect, and a less empowering editor. And all this for UI that 99% of your users won't see.
It just doesn't seem like a opportunity cost savvy way to build a website.
Then there are the UIs that take some real backsplits to accomplish without Javascript like a table that lets you mass-modify the rows with checkboxes and a <select> at the top that lets you choose options like Move | Archive | Delete.
You can wrap the entire <table> with a <form> such that all of your checkboxes submit to your mass-modify endpoint. That works without JS.
But since you can't nest <form> within other <form>, your <form method="DELETE" action="/things/{id}"> delete buttons can't appear in each row.
I have a hard time understanding how so many people in these threads can suggest that the opportunity cost of building for the 1% is always worth it. Does everyone just have basic blogs on the mind when they envision the labor involved in what they preach?