I simply will not spend time tailoring a nascent or even mature product to 0.0001% or whatever minscule percentage of the population turns off JS. If you turn off JS, you get a blank screen. Why should I accommodate your cohort? Why write unit tests for someone who takes a standardish client with above 1% market share and does something completely unstandard with it?

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.

Websites shouldn't break if you disable CSS - just look worse. The text should still be perfectly readable and images viewable.

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.

Where does the cost of making a blog readable without javascript com from? It takes a lot of extra effort to make a blog that requires javascript.

As far as I'm concerned, if it's not readable without javascript then you've got nothing intelligent to say anyway.

>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.

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 agree almost fully.

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).

In my experience, optimizing for perceived latency (time between user request sent and site becoming usable) inevitably leads to server side rendering, in geographically distributed availability zones. If you know this in advance, then you can choose to use tools that support code reuse across the client/server divide. This way, SSR is mostly a one time cost, and it can be implemented at the very beginning of the project, while everything is still nice and simple. It does impose additional constraints during UI development, but many of those are good practices anyway (proper use of HTML elements, prefer native form elements to fully custom inputs, use URL and history to manage state, etc).

It has been somewhat humbling to watch users on low speed connections use the app before the JS finishes loading; it shows everyone the true value (or lack thereof, for the passive content consumers who make up ~98% of the visitors) of the JS portion of the app, since they see it with and without JS. Sure, they can't drag a box on my fancy visualization, but they can see a snapshot of it, and use the peripheral controls as links to navigate to the desired application state. Then, as they are reading something that is useful to them, the ~2mb JS blob slips in and quietly brings the application to life.

Also, I love the way the 3rd party JS blobs that management mandated, are so obviously slower than the rest of the page. This gives me good ammunition for the arguments where I demand an HTTP API, not a JS blob, from our partners. They hate that, because then they can't stuff their own trackers into our clients. Fork 'em.

I use NoScript. If a site interests me I unblock it, I may also unblock one or two external scripts. What I encounter quite commonly is a list of 40 external scripts, which results in a closed tab. There is reasonable use of JavaScript and then there are web devs. playing gotta catch them all with tracking scripts and, at the risk of repeating myself, social media integration.

> For the same reason we build features in websites that work for blind people (aria tags everywhere), disabled people (accessible buttons), people who speak different languages (i18n), VIM users (GMail keyboard shortcuts), etc.

From a comment below.

Great counter example, thank you. Accompdating people with disabilities is totally worth it though imo, as an example of a very minor cohort that's not all about percentages.

I use Vimium in Chrome to be able to use the keyboard to navigate web pages. Gmail in particular conflicts with this by implementing its own keyboard shortcuts that interfere with my workflow.

Some people may like it, but I'm just saying that it's not a feature that isn't disliked by some people.

Agreed. Before reading further down I commented on another response with a similar message.

Supporting a JS-disabled experience should not be your first priority. But, reducing needless reliance on javascript will improve your site for every user - making the page load / respond faster, use less CPU and memory, etc. It will also improve the development experience for you - faster to test, less crazy codebase to work in. It's really just architecting the site better.

Some people are so scared of "premature optimization" and "catering to a tiny number of geeks" that they trick themselves into making a huge JS mess. Most websites these days seem to be examples of this.

It really depends on your pages.

If you are building a blog or a news site (a classic "content" site), it should absolutely work without javascript.

If you are building an admin interface for said news site, where articles are edited and published, it is okay to require javascript.

because its good engineering. you don't know what might break your JS in the future. you also don't know which user agents people will use in the future. I was quite surprised to discover that some "UC browser for Android" had quietly racked up a 9% usage[^1]. UC doesn't come without JS, but has a limited feature set, and without feature testing there's a good chance it will break your site. It broke [mine](https://qwtel.com/hydejack/), if it wasn't for feature testing and serving vanilla HTML. Also, and I know it seems impossible, but sometimes programmers ship broken code. Again, not relying on JS gives you safety net to fall back on.

[^1]: http://caniuse.com/usage-table

Nonsense. This is definitively YAGNI. Good engineering is accommodating the greatest number of people with the resources you have in the least amount of time. Thinking about some abstract future scenario is categorically not good engineering.

You misspelled "good bean-counting". Good engineering requires you to cover for everything you can.

Case in point: car seatbelts and airbags. Most people don't crash, right? But you aren't seeing the car manufacturers remove seatbelts and airbags.

You also don't see car manufacturers change their designs so that they will accommodate drivers who've decided to remove their steering wheel, nor do car manufacturers design their cars for some possible future world without gasoline.

I've had this one coming. Serves me right to believe contrived example won't be nitpicked. :D

When everything is made from beans, the bean supply must be kept in mind.

Consumers by in large know driving is dangerous and safety features are something car manufacturers advertise to consumers. Not to mention over the last 30-40 years drivers have come to expect these sorts of features in cars because accidents happens and those features increase survivability, by a lot.

The same sort of consumer expectation doesn't exist for no-javascript. Major browsers default it enabled. The web has developed to be seriously built on top of javascript for the last 15 years. Consumers have expectations for how the web should work in 2017 (for better or worse) and no-javascript isn't anywhere on the radar.

Consumer expect cars to have airbags and seatbelts, consumers expect websites to behave as they always have and that means javascript.

JS is necessary. But what do we do about the extensive tracking and extremely unoptimal requests, for which we already have numerous articles out there?

If there's no soft solution, disabling JS altogether is a good fish net for a lot of people -- yes the percent is close to a rounding error but the absolute amount can go to 1 million or more.

Counter point: many cars aren't made to accommodate people as tall as a professional basketball player. Should I call them all bad (or at least not good) engineering?

Counter-counter-point: I am above 180cm (far from 200+ where many basketball players are) and many taxis aren't tuned for me and I bang my head on the ceiling so yes, I definitely call the manufacturers of those cars bad.

Statistical averages are a back-patting technique between managers, let's face that reality, shall we? They very rarely have the customer's interests in mind.

You have to draw a line somewhere, though. Every engineering decision has a cost, whether time/money, opportunity cost, or design tradeoffs, so it's not practical to cater to every single user you have.

There are many people above 180cm.

Again, let's face it -- it's bean counting, some medium-level product manager wants a raise by saving expenses.

That's all it is, that's all it ever was, and it ain't ever gonna change while there are people on these positions.

Good engineering requires good bean-counting. Figuring out what you can do with infinite resources is not good engineering (except perhaps when funded by DARPA).

As any good civil engineer knows... “Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands.”

The essential characteristic of engineering is making mindful, appropriate tradeoffs between various costs and benefits, including features, risks, externalities, financial costs, etc.

As I mentioned in another comment, it was a bit exaggerated example to illustrate a point, not to make the people nitpick it.

The corner-cutting in the current tech culture is a bit too much for my taste.

what a ludicrous analogy. engineering is an applied science, not a purely theoretical one where you can remove the human impact of your decisions from the equation. comments like this are a prime example of why engineers need to take more liberal arts classes

I agree with you about liberal arts and have the college transcripts to prove it. Unfortunately, your HN comments have been frequently uncivil and/or unsubstantive. Would you please not post like that? It's just what we're trying to avoid here.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

Would you be so kind to point out how would a liberal art knowledge would help people like me understanding the issues better?

I think I understand where my opponents stand, but I disagree with a part of them.

I don't know how the point applies in this case, or if it does at all. It's pretty hard to draw specific lines like that.

It was a slightly exaggerated example. Nothing can be infinitely optimized of course, but the corner cutting in today's tech culture is a bit too much for my taste.

you're right. let's get rid of safety nets, because YAGNI. it's so efficient!

> If you turn off JS, you get a blank screen.

I browse with JS on (but I block ads and most tracking scripts) and only use a separate browser profile with JS off for sites that look fishy.

Requiring JS for a web app or interactive features in a website is fine.

A few years ago I had to use an old PC for a while, and disabling JS by default improved my experience significantly, but too many websites simply didn't display any content without JS, or didn't load images. The "web apps vs. web pages" debate has been beaten to death, but being unable to e.g. read a blog post without enabling JS just feels wrong to me.

I'm not sure if things are as bad now.

>I simply will not spend time tailoring a nascent or even mature product to 0.0001% or whatever minscule percentage of the population turns off JS.

This is reasonable logic and I think it is an important point in getting more people into a technology movement, whether it is removing JS or anything else. A similar example is getting encrytion: many users don't know or care to use it, so it is usually a side issue if mentioned at all in a company. But if the percentage of people who do use it increases, companies will have a greater interest in supporting it.

Currently, normal users just care that content loads when the click the link for a website, and perhaps don't understand or care that JS is running or what the consequences of that is. A more constructive way to get better experience without JS is to ask others to also block it to show companies that this is an issue, rather than just directly asking companies to add support.

It might make sense to think about who disables JS. Likely it's technically knowledgeable people with a concern for privacy and security. If this describes your users or customers you may benefit from at least some level of non-JS functionality.

those knowledgeable users might be installing JS blockers in their friends and family computers right now.

And then they get "since you played with my computer the internet doesn't work properly".

"you broke google!"

That sound fine if you don't see any problems with showing a blank page for no-js which was supposed to displays only some texts/images/links.

Adobe flash is dead since many years, people that was warned that they should not do only flash website,and for the same people can browse without JS what you tell them now? they site aren't at all usefull, you failed. All website or software should never fail so easily. I truly support jaclaz. No message : you should use blablabla, or enable this, or anything else, people goes away.

I agree, maybe kids at Google get paid big wedges for this, I don't

Even though I am a frequent advocate of leaning on more old school techniques for building web apps (even with new school tools), I vehemently disagree that this is a generally worthy cause. A small list of (I think non-controversial) things:

1. You browse without JS. You're a power user. You already know why the page doesn't work. A courtesy message would be nice, I guess, but it seems fairly pointless.

2. Should my HTML and CSS still target IE7-friendliness? IE7 users still have more market share than actual humans who browse without JS. They get treated like lepers in the Year 0, and we all seem to be okay with that.

3. Well-designed use of JS can help distribute computation load that might otherwise all fall on the server. A very contrived-to-be-important (but fairly common) example of this is scaling/cropping an image before it's uploaded. Or, even though I have some other reasons to hate on SPAs, page rendering itself. The no-JS user is more expensive to serve than the typical user.

4. Except for some extreme cases of JS reliance, search engine spiders are a head and shoulders more accommodating to developers' choices than no-JS users are.

I just don't think that making accommodations for no-JS power users, who are not plentiful, and know full well how to turn JS back on, is valuable. Making JS bundles smaller and making them load more efficiently? That's a worthy cause for sure. But people who browse without JS at all are extreme outliers in the 1st world, and all of them know how to toggle it back on. Developing countries? If I were trying to serve those users I would do the research and make choices accordingly.

>1. You browse without JS. You're a power user. You already know why the page doesn't work. A courtesy message would be nice, I guess, but it seems fairly pointless.

Well, the point is that a lot of people post their site on HN as "Show HN", and the "intended audience" is then (or should be) "power users", which should also mean that "power users" (few as they might be) are potentially interested to your site, but you make sure that only a subset of these power users can access your site (not necessarily in full, sometimes a simple text summing up what the thing is about would be enough to either - as I do if the page doesn't load - discard it or get me interested enough to turn javascript on/use the "other" browser).

If you don't post your site on "Show HN" the missing "no-javascript message" is only a (small) lack of courtesy, if you do post it, it sounds (to me) like a plain lack of attention.

In the real world, you open a new shop in town, and advertise on the local newspaper "everyone is invited for the shop opening tuesday at 7:00 P.M.", than you put at the door a couple big guys that only let in those dressed "black tie". I do have a suitable attire, but I am not going home to change into it, not without having at least the possibility to peek inside your shop and see what it is about. Will I become a customer? Maybe yes, maybe not, but more likely not.

I would see it as more equivalent to a "No shirt. No shoes. No service." sign. The vast majority of people will already meet the criteria, and those that don't are already well aware that they are likely to run into problems.

This is only a valid analogy if in our real world I could make a tuxedo appear on my body with no more effort than snapping my fingers. (Which would be awesome.)

Honestly if you're so persistent that you must have a message that you need Javascript then you're not the type of customer I want viewing my site anyway. Someone that picky will find another problem anyway.

For #2 (JS abuse by site owners) I wonder if it might be useful to set size limits, like: maximum allowed bytes per resource type (.js, .css, .*), per file and per page, possibly with some local-vs-remote adjustments.

You could just read the Content-Length header and drop the connection if the site is over the user's limits (at which point you'd want to display a status message instead of the partial site).

The sites that REALLY piss me off are the ones with a timed redirect like:

<meta http-equiv="refresh" content="1;url=http://www.example.com/nojavascript" />

which show a usable flash of the site for one second and then bounce me to a useless "You must enable JavaScript to use this site." page. By the flash I know that this is technically not correct.

NoScript includes a toggle to disable exactly this behaviour (meta tags within noscript tags). meta refreshes in general are pretty annoying as a user though

One problem is that more and more, people expect the browsing experience to include a lot of responsive features that require a bunch of client-side JavaScript.

Except JavaScript blows, the emerging JS extension ecosystem that tries to fix that is still highly in flux (and mostly blows), so developers try to keep their server-side stuff NOT JavaScript, and then supporting server-side rendering means re-implementing everything twice.

Of course, this doesn't excuse document-centric sites like news and blogs.

1) It's irrelevant since it's the only language we have on the browser.

2) I think this is actually a cultural problem. Are users steering away from overcomplex/bloated/intrusive websites? If not, why not?

3) That's an argument similar to should a site support IE8? IMO it really boils down to the cost vs the benefit of supporting user without JS. And that of course will depend on your target users.

>#1 is largely a matter of personal opinions

>This is wrong.

... in your opinion ...

>>>#1 is largely a matter of personal opinions

>>This is wrong.

>... in your opinion ...

Yep. But sometimes my opinion is right ;-)