3 ms·

Explain yourself why we "always need a fallback plan" if JS is disabled. Without saying "screen readers", as they're 90%+ JS enabled these days.

instakill 13y ago
Because millions of people use Opera Mini 4.x which does not support most JavaScript functions.
- sutterbomb 13y ago
  Millions of people are not using Opera Mini 4.x on any sites I actually work on. They constitute a small fraction of a percent of total visitors. The opportunity cost of developing fallbacks for them is simply too high when we could be developing additional improvements for the vast majority of our userbase.
  - PavlovsCat 13y ago
    Additional improvements, or bling? That's kind of the point, breaking functionality for mere shinyness is silly. If you need javascript anyway, that's different of course.
- mantrax4 13y ago
  We're talking about a submit button here. You're claiming, millions are filling in long web forms with their feature phone numpad keys? Give me a break.
oneeyedpigeon 13y ago
So that the site still functions if JS is disabled or unavailable, which can happen for many reasons including network policy, browser support, personal preference, availability (especially if you're hosting the JS on a separate server), or bugs in the source. Explain why you would choose NOT to implement a fallback plan, given that 99%+ of the time it is trivial to do so.
- mantrax4 13y ago
  If half my resources aren't loading, or aren't loading in full, despite all the fallbacks built into HTTP itself to avoid precisely that scenario, there's no fallback on Earth that can work around this. If my JS would load in half, my no-JS form might also load in half, what do we do now. Have a fallback where we accept the form in pieces? As for people who have a "personal preference", well, they might as well have a personal preference to browse the web via telnet. It's their problem. The requirement to use a full, working web browser to browse a web page is hardly extreme.
  - oneeyedpigeon 13y ago
    Let's say your JS is hosted on a different domain from your html (quite a common scenario) and that domain can't be reached (for any of the many possible reasons). Or a bug is introduced into the javascript (which happens a lot). In each case, your approach results in a broken page, whilst a fallback approach still works perfectly. Re: personal preference - have you never heard the saying 'the customer is always right'? No business in its right mind would purposefully turn down money from a bunch of its customers just because they happen to have a personal preference which can easily be accommodated. Note that a web browser without javascript support doesn't fail to be a 'working browser' just because you say so. Note that I am not saying you must do this on your personal blog, or that Javascript isn't a very useful feature of today's modern browsers. Just that it's good engineering practice to be inclusive and to handle exceptions gracefully.
ssorallen 13y ago
I don't do this for when JS is disabled; I do this because networks are unreliable, especially cellular ones. JS on websites is growing in number of files and in number of bytes. If your JS is at the bottom of the page and has to download and execute before the page is usable, users on cellular networks in particular can be looking at an unusable page for a significant number of seconds.

instakill 13y ago

Because millions of people use Opera Mini 4.x which does not support most JavaScript functions.

sutterbomb 13y ago
Millions of people are not using Opera Mini 4.x on any sites I actually work on. They constitute a small fraction of a percent of total visitors. The opportunity cost of developing fallbacks for them is simply too high when we could be developing additional improvements for the vast majority of our userbase.
- PavlovsCat 13y ago
  Additional improvements, or bling? That's kind of the point, breaking functionality for mere shinyness is silly. If you need javascript anyway, that's different of course.
mantrax4 13y ago
We're talking about a submit button here. You're claiming, millions are filling in long web forms with their feature phone numpad keys? Give me a break.

oneeyedpigeon 13y ago

So that the site still functions if JS is disabled or unavailable, which can happen for many reasons including network policy, browser support, personal preference, availability (especially if you're hosting the JS on a separate server), or bugs in the source. Explain why you would choose NOT to implement a fallback plan, given that 99%+ of the time it is trivial to do so.

mantrax4 13y ago
If half my resources aren't loading, or aren't loading in full, despite all the fallbacks built into HTTP itself to avoid precisely that scenario, there's no fallback on Earth that can work around this. If my JS would load in half, my no-JS form might also load in half, what do we do now. Have a fallback where we accept the form in pieces? As for people who have a "personal preference", well, they might as well have a personal preference to browse the web via telnet. It's their problem. The requirement to use a full, working web browser to browse a web page is hardly extreme.
- oneeyedpigeon 13y ago
  Let's say your JS is hosted on a different domain from your html (quite a common scenario) and that domain can't be reached (for any of the many possible reasons). Or a bug is introduced into the javascript (which happens a lot). In each case, your approach results in a broken page, whilst a fallback approach still works perfectly. Re: personal preference - have you never heard the saying 'the customer is always right'? No business in its right mind would purposefully turn down money from a bunch of its customers just because they happen to have a personal preference which can easily be accommodated. Note that a web browser without javascript support doesn't fail to be a 'working browser' just because you say so. Note that I am not saying you must do this on your personal blog, or that Javascript isn't a very useful feature of today's modern browsers. Just that it's good engineering practice to be inclusive and to handle exceptions gracefully.

ssorallen 13y ago

I don't do this for when JS is disabled; I do this because networks are unreliable, especially cellular ones. JS on websites is growing in number of files and in number of bytes. If your JS is at the bottom of the page and has to download and execute before the page is usable, users on cellular networks in particular can be looking at an unusable page for a significant number of seconds.