I find that it's at least (usually more) double the work to build the JS-free version of something for a fraction of the user experience.
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?
Non js users aren't expecting the website to work perfectly without scripts on. The bare minimum they ask for is that the site can be read without using scripts. Obviously it would be nice if all the moving components didn't need scripts either, but most people can accept that this is too much work.
Depending on the site, even just reading may be problematic. Imagine a webapp where all data is requested and sent as small JSON updates. This is faster and it's less data than full page copies, and can be more targeted to that user.
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.
That's an unreasonable expectation. Many websites have complex content and layouts, and no web designer will build their site to gracefully fall back with CSS disabled. That just doesn't happen.
It does happen when the developer cares to do it; I know several that do.
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.
For me, yes. I should be able to see at least the main content of your blog without JS. I don't care if it's perfectly formatted or styled. Just put the text in a div.
When I go to a blog post linked from HN and see a white empty page I will just move on.
Good. Please leave. I don't walk into a restaurant and demand that they cook my food without using a knife. Don't expect modern websites to bend over backwards for a (frankly rather juvenile) view of a modern web standard.
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.
A blog post is one thing, but many web developers that venture onto this site -- myself included -- are building complex web applications that would simply not make any sense as a "read only" website.
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.
> 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.
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.
When you add up all of the ridiculous hoops web developers have to jump through for cross-browser compatibility, a non-JS UX is the least of their concerns.
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?