6 ms·

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 o

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?

qwtel 9y ago
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/ 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 http://caniuse.com/usage-table
- linkmotif 9y ago
  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.
  - qwtel 9y ago
    you're right. let's get rid of safety nets, because YAGNI. it's so efficient!
  - throwaway47861 9y ago
    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.
    - to3m 9y ago
      When everything is made from beans, the bean supply must be kept in mind.
    - sbov 9y ago
      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?
      - throwaway47861 9y ago
        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.
        RussianCow 9y ago
        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.
        throwaway47861 9y ago
        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.
    - che_shirecat 9y ago
      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
thinkxl 9y ago
> 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.
- linkmotif 9y ago
  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.
- 52-6F-62 9y ago
  Agreed. Before reading further down I commented on another response with a similar message.
- lokedhs 9y ago
  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.
always_good 9y ago
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?
- 52-6F-62 9y ago
  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).
- ams6110 9y ago
  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.
ams6110 9y ago
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.
- gpderetta 9y ago
  those knowledgeable users might be installing JS blockers in their friends and family computers right now.
  - mathw 9y ago
    And then they get "since you played with my computer the internet doesn't work properly".
    - gpderetta 9y ago
      "you broke google!"
josefx 9y ago
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.
madshiva 9y ago
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.
dictum 9y ago
> 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.
ptr_void 9y ago
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.
devrandomguy 9y ago
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.
ploxiln 9y ago
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.
- fenwick67 9y ago
  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.
Fifer82 9y ago
I agree, maybe kids at Google get paid big wedges for this, I don't
TwiSparklePony 9y ago
>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.

qwtel 9y ago

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/ 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 http://caniuse.com/usage-table

linkmotif 9y ago
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.
- qwtel 9y ago
  you're right. let's get rid of safety nets, because YAGNI. it's so efficient!
- throwaway47861 9y ago
  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.
  - to3m 9y ago
    When everything is made from beans, the bean supply must be kept in mind.
  - sbov 9y ago
    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?
    - throwaway47861 9y ago
      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.
      - RussianCow 9y ago
        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.
        throwaway47861 9y ago
        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.
  - che_shirecat 9y ago
    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

thinkxl 9y ago

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

linkmotif 9y ago
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.
52-6F-62 9y ago
Agreed. Before reading further down I commented on another response with a similar message.
lokedhs 9y ago
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.

always_good 9y ago

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?

52-6F-62 9y ago
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).
ams6110 9y ago
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.

ams6110 9y ago

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.

gpderetta 9y ago
those knowledgeable users might be installing JS blockers in their friends and family computers right now.
- mathw 9y ago
  And then they get "since you played with my computer the internet doesn't work properly".
  - gpderetta 9y ago
    "you broke google!"

josefx 9y ago

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.

madshiva 9y ago

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.

dictum 9y ago

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

ptr_void 9y ago

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.

devrandomguy 9y ago

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.

ploxiln 9y ago

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.

fenwick67 9y ago
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.

Fifer82 9y ago

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

TwiSparklePony 9y ago

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