3 ms·

> "failure to handle disabled js gracefully." How are we meant to handle AJAX requests that fetch data to display on the web page that allows users to achieve

by exodust 13y ago

> "failure to handle disabled js gracefully." How are we meant to handle AJAX requests that fetch data to display on the web page that allows users to achieve the goal of their visit? Without JS enabled, that part of the page will be blank, and many modern, rich content-heavy sites now pull data from different places on the fly, it's just how it is. Is your idea of gracefully handling this situation putting a noscript tag there saying "please enable JS"? If so, what exactly is your problem with removing the option which we only ask users to re-enable anyway? As many others have pointed out, you can still disable JS if you really need to. It's average non-technical users who don't require that option.

dthunt 13y ago
Let's not forget that not every page is meant for humans to read, and not every reader is attempting to consume information the same high-bandwidth (visual) way. You might think AJAX is amazing, but I call it an accessibility nightmare.
- exodust 13y ago
  I know exactly what you mean by AJAX being an accessibility nightmare, and perhaps my own recent over-indulgence in using AJAX to populate the website I made will come back to bite. Time will tell, and I'm willing to eat humble pie over it. But in my defense the client's requirement was to get that content on the page, and AJAX was the only method available to me.
Isofarro 13y ago
> How are we meant to handle AJAX requests that fetch data to display on the web page that allows users to achieve the goal of their visit? Make the request from your server, parse it on your server, template it on your server, and deliver the HTML result to your user. > Without JS enabled, that part of the page will be blank, and many modern, rich content-heavy sites now pull data from different places on the fly, it's just how it is. Perhaps the developers of these modern, rich content-heavy sites can learn how to do their jobs properly? > Is your idea of gracefully handling this situation putting a noscript tag there saying "please enable JS"? No. It goes far deeper than that, naturally. Progressive enhancement ( https://www.gov.uk/service-manual/making-software/progressive-enhancement.html https://www.gov.uk/service-manual/making-software/progressiv... ) is about defining what is considered the core experience, defining the true value your site offers to your users, identifying the use cases that are utterly essential. It's these features that should be _implemented_ in a way that doesn't depend on JavaScript. So you build this layer first, and get it working. Then, you identify the enhancements, user experience improvements, the bells & whistles, and use JavaScript to fill in those gaps. Confident in the knowledge that should the JavaScript fail (for a plethora of different and uncontrollable reasons) the core experience will continue working. Then you consider the nice-to-have features, and decide how much of that is appropriate to incorporate as a core-experience level, and what improvements can be made with JavaScript.
- exodust 13y ago
  Sounds cool, but speaking from recent experience, the option to make the request from the server, parse it on the server, template it and deliver it was not available to me for the job I was asked to do (as a frontend developer). Sometimes it comes down to doing it with client side AJAX, or not doing it at all. With developers learning to do their jobs properly, sure when the luxury of time and starting a new site from scratch is on your side. And with backend developers and engineers ready to configure the ultimate content delivery mechanisms. But what of when you don't have that luxury? What then? Just decline the job? Maybe, but then someone else will come along and do the AJAX, and get paid because the content appears when the site loads every single time (provided JS is enabled ;-).
  - deleted 13y ago
    [deleted]

by exodust 13y ago

dthunt 13y ago

Let's not forget that not every page is meant for humans to read, and not every reader is attempting to consume information the same high-bandwidth (visual) way. You might think AJAX is amazing, but I call it an accessibility nightmare.

exodust 13y ago
I know exactly what you mean by AJAX being an accessibility nightmare, and perhaps my own recent over-indulgence in using AJAX to populate the website I made will come back to bite. Time will tell, and I'm willing to eat humble pie over it. But in my defense the client's requirement was to get that content on the page, and AJAX was the only method available to me.

Isofarro 13y ago

> How are we meant to handle AJAX requests that fetch data to display on the web page that allows users to achieve the goal of their visit? Make the request from your server, parse it on your server, template it on your server, and deliver the HTML result to your user. > Without JS enabled, that part of the page will be blank, and many modern, rich content-heavy sites now pull data from different places on the fly, it's just how it is. Perhaps the developers of these modern, rich content-heavy sites can learn how to do their jobs properly? > Is your idea of gracefully handling this situation putting a noscript tag there saying "please enable JS"? No. It goes far deeper than that, naturally. Progressive enhancement ( https://www.gov.uk/service-manual/making-software/progressive-enhancement.html https://www.gov.uk/service-manual/making-software/progressiv... ) is about defining what is considered the core experience, defining the true value your site offers to your users, identifying the use cases that are utterly essential. It's these features that should be _implemented_ in a way that doesn't depend on JavaScript. So you build this layer first, and get it working. Then, you identify the enhancements, user experience improvements, the bells & whistles, and use JavaScript to fill in those gaps. Confident in the knowledge that should the JavaScript fail (for a plethora of different and uncontrollable reasons) the core experience will continue working. Then you consider the nice-to-have features, and decide how much of that is appropriate to incorporate as a core-experience level, and what improvements can be made with JavaScript.

exodust 13y ago
Sounds cool, but speaking from recent experience, the option to make the request from the server, parse it on the server, template it and deliver it was not available to me for the job I was asked to do (as a frontend developer). Sometimes it comes down to doing it with client side AJAX, or not doing it at all. With developers learning to do their jobs properly, sure when the luxury of time and starting a new site from scratch is on your side. And with backend developers and engineers ready to configure the ultimate content delivery mechanisms. But what of when you don't have that luxury? What then? Just decline the job? Maybe, but then someone else will come along and do the AJAX, and get paid because the content appears when the site loads every single time (provided JS is enabled ;-).
- deleted 13y ago
  [deleted]