Ask HN: do you design websites so that they work without JavaScript?
I know it may seem like a controversial thing to ask, but I'm asking seriously.
When you design a web application today, do you plan for graceful degradation if someone has JavaScript turned off? If so, why?
I am trying to figure out the cost/benefit ratio of graceful degradation. I've spent some time online with JavaScript turned off today and it wasn't a pleasant experience. My guess is that very few have it switched off. JavaScript penetration is estimated around 98%.
Accessibility used to be the reason, but should be no more: you can create accessible sites with JavaScript. Mobile devices? Dominant mobile browsers now support JavaScript.
So what are your reasons for graceful degradation?
7 comments
[ 5.4 ms ] story [ 34.9 ms ] threadNormally, you need to start by breaking down what sections of an app absolutely need js code to work. Regular forms dont need any js to run. You can have a fancy form that falls back to a basic form.
Also, don't rely on js 100% for styling. Use css for everything. Except for ie6 and :hover. Bloody IE...
But even when i do develop public facing websites, deciding to put in the effort for graceful degradation depends on your target audience.
These days i find more clients asking for UI features on websites that cannot degrade gracefully at all. Again, depends on your audience.
The trick is not to think in terms of 'supporting graceful degradation', but in terms of 'javascript enhancements'.
Which means, do your entire app to work in html. Then add javascript wherever you can to enhance the app.
Force all your javascript to run /after/ the page loads, it's a constraint that will stop you from cheating.
An example is a delete button. Do it in html as so:
Then, with your framework of choice (jquery here): (Code untested)So instead of the delete button causing you to go to a new page, it will just popup a confirmation, and when you click 'ok' will do the ajax call, and change the button into a 'Deleted!' message.
With a decent framework, the code to 'enhance' will maybe add a tiny bit of overhead in terms of loc and time, (this example for instance, 3 lines more than if it was javascript only).
But you get a much easier to debug app and it works everywhere to boot.
That is what you should start trying to avoid. Do it the other way around:
- Start with a url that outputs the correct table according to params.
- Return the correct data type, eg. json/html from the same url using your method of choice (url extension/Accept header)
- When you want a javascript enhancement to, eg. convert the table to a live spreadsheet that flushes changes after you change a cell via ajax just do it. Make the fields editable (or replace them with input boxes, whatever you fancy) and hook their 'onchange' event.
This is why I don't like things like YUI datatable, or very full stack frameworks in general, I prefer to have a small useful library that gives me the tools so I can do exactly what I want with albeit a little effort, but mostly very simple.
Far more flexible than creating a datagrid with 4 lines of framework code but hitting a roadblock the moment something different needs to be done.
Thanks -- I don't necessarily agree, but it is a good answer and a valid point of view.