7 ms·

I think I gathered this, but my point is why does this matter? If I run a site that is unreadable on NoScript and RequestPolicy turned up to maximum paranoia, b

by gfodor 12y ago

I think I gathered this, but my point is why does this matter? If I run a site that is unreadable on NoScript and RequestPolicy turned up to maximum paranoia, but am generating millions of dollars of revenue, is my webpage "broken?" If only 0.01% of my users actually are affected by such a thing, and I don't care about that, is it still "broken?" If a webpage has a missing closing </div> tag, but is never hit by a human being, is it still broken? I guess what I'm getting at is as I've gotten older I've grown less and less empathetic to arguments that seem to appeal to an engineer's sense of purity, correctness, and craftsmanship and not much else. Tie it to user pleasure, effectiveness, business metrics, anything, but citing the idea that somehow since the web was not designed with Javascript everywhere in mind meaning we should use it as the exception not the rule isn't much more than appeal to tradition argument to me. There are definitely areas of software engineering where you can find many examples where a lack of respect for the craft, or a lack of knowledge of history/standards results in failure, but I'm just not buying the idea that if you build a SPA with a fancy new javascript framework instead of making sure NoScript works you're somehow going to be paying for that in spades down the road because it's breaking some set of rules handed down by the high priests. There are about a million other technical decisions that have more of an impact in a serious project. (For example, instead of arguing about SPA vs non-SPA, or what framework, or whatever, ask yourself: "Is anyone on the team an expert in any particular flavor of this?" If the answer is "yes", then going with any one of those is almost certainly the best strategic decision regardless of the supposed merits or flaws of that particular approach.)

lstamour 12y ago
The big reason to avoid shipping a white page with JS turned off is performance. It implies that at some point, the JS will load and you can stop using ng-cloak or whatever else is hiding in the blank space. It's better to pre-load actual content, or if you don't have that, fake content, then to show nothing at all. Similarly, it's better to pay attention to back buttons so your users can navigate a website using built-in controls. This is especially important on phones, where it's easy to click a wrong link, and where back is literally a button. Can you do this with JS? Yes. Is it obvious? Not always. The same was true with our use of CSS over images, or web fonts over flash. Eventually the industry will move in the right direction, it just takes time and the occasional rant or two. ;-)
aikah 12y ago
> If only 0.01% of my users actually are affected by such a thing All users don't have the same value. And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. You might not care today,but when it's time to care, well your competitor that cared will get the users and the revenue lost because "you didn't care".
- mklim 12y ago
  > And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. Do you have any data to back that up? In my experience it seems like the number of people who turn JS off by default has declined since SPAs became so common. It looks like the search trend for Noscript has been gradually declining since 2009, while Adblock has risen: http://www.google.com/trends/explore#q=noscript%2C%20adblock&cmpt=q&tz= http://www.google.com/trends/explore#q=noscript%2C%20adblock...
- gfodor 12y ago
  This should have a huge *citation needed. There are a million decisions you make which affect user adoption and retention of a software product, deciding to support NoScript users is a small grain of sand in that desert. Your claim that this facet of all those decisions will result in a competitor stealing market share completely ignores the concept of engineering tradeoffs. The competitor that "cared" about noscript visitors may spend many man hours (in direct costs or opportunity cost) supporting those visitors, time may be best spent building better competitive differentiators for a larger number of visitors. No design decision lives in a vacuum, and in my own experience designing to support non-JS visitors is almost universally faaaar down the list of priorities if there are good reasons to not do so.
  - aikah 12y ago
    > the concept of engineering tradeoffs. supporting no script is as simple as not abusing javascript in the client.I fail to see how you'd spend more man hours when not investing in these full client-side javascript frameworks when your product can work without using javascript to begin with.
crdoconnor 12y ago
>0.01% 13%, actually, globally. 2% in the US (population of NYC): http://www.searchenginepeople.com/blog/stats-no-javascript.html http://www.searchenginepeople.com/blog/stats-no-javascript.h... That doesn't even count people who use browsers which you haven't tested with obscure bugs, or people who have laggy and slow connections that also breaks or damages the functionality of your javascript heavy web app.
- gfodor 12y ago
  The point wasn't the number, the point was if only a small % of my users are affected by a given design decision, why should I care? Beyond that, website populations have bias and as such citing national/global stats is at best a first order approximation of the impact of not supporting non-JS visitors.
  - crdoconnor 12y ago
    >why should I care? I explained why. For people who use browsers who you haven't tested which break the JS in obscure ways, not to mention people whose experience breaks in obscure ways because of dropped packets and high lag. >Beyond that, website populations have bias and as such citing national/global stats is at best a first order approximation Ironic complaint from somebody whose first guess was two to three orders of magnitude off.
    - gfodor 12y ago
      2% of my users can have javascript turned off and yet only 1% of those people may be negatively affected by the decision to not ensure all features of my site work without it. but go on, keep missing the wider point by being pedantic.
archagon 12y ago
Plus, it's just railing against the tide. I don't disable JS. None of my friends disable JS. (In fact, most of my friends don't even know what JS is.) The setting to disable JS is hidden away in some obscure pref pane in most browsers. It's not going anywhere, it's not optional, and pretending that a site is "broken" if it doesn't work for a handful of geeks is being willfully obtuse.
- lstamour 12y ago
  Actually, didn't Firefox already remove the checkbox? It's probably now only visible under about:config...
- philbo 12y ago
  It's worth noting that "disabling JS" is not the only way to disable JS. Sometimes it can happen inadvertently: * Bug accidentally makes it into production, preventing some crucial feature from working? JS just got disabled. * User is browsing your site with an old device that doesn't support a feature you make use of? That JS has been disabled. * CDN fails and your fallback mechanism isn't working like you thought it was? JS got disabled. Not saying these are common occurrences, but I've seen all of them happen.
ForHackernews 12y ago
How about screen-readers and other assistive software for visually impaired users? Apparently they've gotten better in recent years, but if you make a website that doesn't work without JavaScript, you're still probably screwing a lot of those people over. Maybe they're a small percentage of your users, but it still strikes me as a dick move in the same category as constructing a building that isn't handicap-accessible (yes, I'm aware there are legal compliance rules in the building trade).
- steveax 12y ago
  It's mostly a myth that relying on JavaScript makes a website inaccessible (partially propagated by the woefully out of date Section 508 requirements in the US - the update is currently in progress and will be very close to WCAG 2.0 [1]). The reality is that very few screenreader users disable JavaScript [2] surprise! they're much like any other user). A properly coded SPA, using aria-* properties is as accessible to most AT users as a traditional server-side application. [1] http://www.w3.org/TR/WCAG20/ http://www.w3.org/TR/WCAG20/ [2] http://webaim.org/projects/screenreadersurvey5/ http://webaim.org/projects/screenreadersurvey5/
viraptor 12y ago
> If I run a site that is unreadable on NoScript and RequestPolicy turned up to maximum paranoia, but am generating millions of dollars of revenue, is my webpage "broken?" I'd say yes. Usable != profitable. Hey, HN is broken, because it will "time-out" pages and you will sometimes get an error when clicking "next" - but that doesn't make it useless. (and for the arc apologists that usually respond to this - I clicked a valid link on this website, I don't care what technology is HN based on) Also, your website would be broken if it was unusable: under anything other than IE, on machines other than PCs, on devices not made in Asia, by people older than 60, etc. None of those prevent it from generating millions of dollars. Then again "broken" doesn't mean you should care. If your goal was just to make millions of dollars, that's fine. Just don't be surprised people call it broken.
- vdaniuk 12y ago
  See, by that standard the word "broken" loses any significant meaning and becomes noise. Why care about anyone calling anything broken then?
  - viraptor 12y ago
    I don't think it's meaningless. It means you're making $X, but ignoring N% of potential audience. If you fix your stuff you could potentially reach them and make $X+Y. Outside of websites: Private healthcare is broken in the US, but works for N% of people who can afford it. Many people live with the status quo. Is it meaningless to call that system broken? If it's a high enough percent, why care about anyone calling it broken? [my answer - because we're aware it could be better, but it requires more work]

by gfodor 12y ago

lstamour 12y ago

The big reason to avoid shipping a white page with JS turned off is performance. It implies that at some point, the JS will load and you can stop using ng-cloak or whatever else is hiding in the blank space. It's better to pre-load actual content, or if you don't have that, fake content, then to show nothing at all. Similarly, it's better to pay attention to back buttons so your users can navigate a website using built-in controls. This is especially important on phones, where it's easy to click a wrong link, and where back is literally a button. Can you do this with JS? Yes. Is it obvious? Not always. The same was true with our use of CSS over images, or web fonts over flash. Eventually the industry will move in the right direction, it just takes time and the occasional rant or two. ;-)

aikah 12y ago

> If only 0.01% of my users actually are affected by such a thing All users don't have the same value. And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. You might not care today,but when it's time to care, well your competitor that cared will get the users and the revenue lost because "you didn't care".

mklim 12y ago
> And it's also about trends.More and more users use addons that block javascript by default,just like more and more users use adblock. Do you have any data to back that up? In my experience it seems like the number of people who turn JS off by default has declined since SPAs became so common. It looks like the search trend for Noscript has been gradually declining since 2009, while Adblock has risen: http://www.google.com/trends/explore#q=noscript%2C%20adblock&cmpt=q&tz= http://www.google.com/trends/explore#q=noscript%2C%20adblock...
gfodor 12y ago
This should have a huge *citation needed. There are a million decisions you make which affect user adoption and retention of a software product, deciding to support NoScript users is a small grain of sand in that desert. Your claim that this facet of all those decisions will result in a competitor stealing market share completely ignores the concept of engineering tradeoffs. The competitor that "cared" about noscript visitors may spend many man hours (in direct costs or opportunity cost) supporting those visitors, time may be best spent building better competitive differentiators for a larger number of visitors. No design decision lives in a vacuum, and in my own experience designing to support non-JS visitors is almost universally faaaar down the list of priorities if there are good reasons to not do so.
- aikah 12y ago
  > the concept of engineering tradeoffs. supporting no script is as simple as not abusing javascript in the client.I fail to see how you'd spend more man hours when not investing in these full client-side javascript frameworks when your product can work without using javascript to begin with.

crdoconnor 12y ago

>0.01% 13%, actually, globally. 2% in the US (population of NYC): http://www.searchenginepeople.com/blog/stats-no-javascript.html http://www.searchenginepeople.com/blog/stats-no-javascript.h... That doesn't even count people who use browsers which you haven't tested with obscure bugs, or people who have laggy and slow connections that also breaks or damages the functionality of your javascript heavy web app.

gfodor 12y ago
The point wasn't the number, the point was if only a small % of my users are affected by a given design decision, why should I care? Beyond that, website populations have bias and as such citing national/global stats is at best a first order approximation of the impact of not supporting non-JS visitors.
- crdoconnor 12y ago
  >why should I care? I explained why. For people who use browsers who you haven't tested which break the JS in obscure ways, not to mention people whose experience breaks in obscure ways because of dropped packets and high lag. >Beyond that, website populations have bias and as such citing national/global stats is at best a first order approximation Ironic complaint from somebody whose first guess was two to three orders of magnitude off.
  - gfodor 12y ago
    2% of my users can have javascript turned off and yet only 1% of those people may be negatively affected by the decision to not ensure all features of my site work without it. but go on, keep missing the wider point by being pedantic.

archagon 12y ago

Plus, it's just railing against the tide. I don't disable JS. None of my friends disable JS. (In fact, most of my friends don't even know what JS is.) The setting to disable JS is hidden away in some obscure pref pane in most browsers. It's not going anywhere, it's not optional, and pretending that a site is "broken" if it doesn't work for a handful of geeks is being willfully obtuse.

lstamour 12y ago
Actually, didn't Firefox already remove the checkbox? It's probably now only visible under about:config...
philbo 12y ago
It's worth noting that "disabling JS" is not the only way to disable JS. Sometimes it can happen inadvertently: * Bug accidentally makes it into production, preventing some crucial feature from working? JS just got disabled. * User is browsing your site with an old device that doesn't support a feature you make use of? That JS has been disabled. * CDN fails and your fallback mechanism isn't working like you thought it was? JS got disabled. Not saying these are common occurrences, but I've seen all of them happen.

ForHackernews 12y ago

How about screen-readers and other assistive software for visually impaired users? Apparently they've gotten better in recent years, but if you make a website that doesn't work without JavaScript, you're still probably screwing a lot of those people over. Maybe they're a small percentage of your users, but it still strikes me as a dick move in the same category as constructing a building that isn't handicap-accessible (yes, I'm aware there are legal compliance rules in the building trade).

steveax 12y ago
It's mostly a myth that relying on JavaScript makes a website inaccessible (partially propagated by the woefully out of date Section 508 requirements in the US - the update is currently in progress and will be very close to WCAG 2.0 [1]). The reality is that very few screenreader users disable JavaScript [2] surprise! they're much like any other user). A properly coded SPA, using aria-* properties is as accessible to most AT users as a traditional server-side application. [1] http://www.w3.org/TR/WCAG20/ http://www.w3.org/TR/WCAG20/ [2] http://webaim.org/projects/screenreadersurvey5/ http://webaim.org/projects/screenreadersurvey5/

viraptor 12y ago

> If I run a site that is unreadable on NoScript and RequestPolicy turned up to maximum paranoia, but am generating millions of dollars of revenue, is my webpage "broken?" I'd say yes. Usable != profitable. Hey, HN is broken, because it will "time-out" pages and you will sometimes get an error when clicking "next" - but that doesn't make it useless. (and for the arc apologists that usually respond to this - I clicked a valid link on this website, I don't care what technology is HN based on) Also, your website would be broken if it was unusable: under anything other than IE, on machines other than PCs, on devices not made in Asia, by people older than 60, etc. None of those prevent it from generating millions of dollars. Then again "broken" doesn't mean you should care. If your goal was just to make millions of dollars, that's fine. Just don't be surprised people call it broken.

vdaniuk 12y ago
See, by that standard the word "broken" loses any significant meaning and becomes noise. Why care about anyone calling anything broken then?
- viraptor 12y ago
  I don't think it's meaningless. It means you're making $X, but ignoring N% of potential audience. If you fix your stuff you could potentially reach them and make $X+Y. Outside of websites: Private healthcare is broken in the US, but works for N% of people who can afford it. Many people live with the status quo. Is it meaningless to call that system broken? If it's a high enough percent, why care about anyone calling it broken? [my answer - because we're aware it could be better, but it requires more work]