4 ms·

I think it depends on the end service. For instance, some critical services would do best to be available without those technical constraints. So for a chat s

I think it depends on the end service. For instance, some critical services would do best to be available without those technical constraints. So for a chat system for video games? Who cares. For my online banking when they no longer staff tellers? It should probably be more of a consideration, or at least offer a parallel, stripped-down portal. Not everyone who needs to access that kind of service has the means for a fast enough computer to run some of the websites out there.

jameshart 5y ago
But all services can choose what they want to support. If I want to play Call of Duty I need to put the disc in an X-Box, not a DVD player. If I want to use google maps, I need to load it in a browser with JS support, not an e-reader.
- 52-6F-62 5y ago
  Funny enough, I think you're saying the same thing I am but looking at it from a different angle. I'm not saying JS-forward web apps shouldn't exist. I'm saying that some services should not only offer JS-forward web apps if their obligatory clientele ranges across the entire spectrum in terms of financial or technological resources and physical ability. Screen readers do not fare well on poorly structured and JS-forward web sites, for example—but the blind still need to access their online banking when their local bank branch removed their tellers and replaced them with a terminal that accesses the web portal alone...
  - jameshart 5y ago
    It's not that simple - modern screenreaders cope pretty well with dynamic UI elements (so long as they are implemented correctly); it's actually pretty unfair to force someone who has a screenreader to keep having to start again at the top of a page and navigate back to where they were every time they interact with the page, because you wanted to keep things simple and clean and just serve up plain markup from a server. Sighted users can keep their place on the page across a reload, but screenreader users might be back to hearing the title and top level nav options again. Remember that what blind users use to interact with plain web navigation is called 'assistive technology' - it adds more interaction options onto plain web pages. You couldn't build such a thing with just HTML. In general, JavaScript offers the opportunity for web-delivered experiences to be improved - for all their users. Browsing with Javascript disabled means you are not going to get to enjoy those benefits. And I don't think that businesses should all feel obliged to try to provide a completely equal experience for someone who chooses to browse with such a restriction.

jameshart 5y ago

But all services can choose what they want to support. If I want to play Call of Duty I need to put the disc in an X-Box, not a DVD player. If I want to use google maps, I need to load it in a browser with JS support, not an e-reader.

52-6F-62 5y ago
Funny enough, I think you're saying the same thing I am but looking at it from a different angle. I'm not saying JS-forward web apps shouldn't exist. I'm saying that some services should not only offer JS-forward web apps if their obligatory clientele ranges across the entire spectrum in terms of financial or technological resources and physical ability. Screen readers do not fare well on poorly structured and JS-forward web sites, for example—but the blind still need to access their online banking when their local bank branch removed their tellers and replaced them with a terminal that accesses the web portal alone...
- jameshart 5y ago
  It's not that simple - modern screenreaders cope pretty well with dynamic UI elements (so long as they are implemented correctly); it's actually pretty unfair to force someone who has a screenreader to keep having to start again at the top of a page and navigate back to where they were every time they interact with the page, because you wanted to keep things simple and clean and just serve up plain markup from a server. Sighted users can keep their place on the page across a reload, but screenreader users might be back to hearing the title and top level nav options again. Remember that what blind users use to interact with plain web navigation is called 'assistive technology' - it adds more interaction options onto plain web pages. You couldn't build such a thing with just HTML. In general, JavaScript offers the opportunity for web-delivered experiences to be improved - for all their users. Browsing with Javascript disabled means you are not going to get to enjoy those benefits. And I don't think that businesses should all feel obliged to try to provide a completely equal experience for someone who chooses to browse with such a restriction.