Ask HN: do you design websites so that they work without JavaScript? | Hacker News Reader

Ask HN: do you design websites so that they work without JavaScript?

8 pointsjwr7 comments

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?

View on HN

Yes, and it's actually easier.

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:

    <form class="delete" action="/delete/something" method="post"><input type="submit" value="delete"></form>

Then, with your framework of choice (jquery here):

    <script>
    runOnLoad(function(){
       $(".delete").submit(function(){
           var form = $(this);
           if (confirm("Are you sure you want to delete this?")) {
               $.post(form.attr("action"), function() {
                   form.replaceWith("Deleted!");
               });
           }
           return false;
       });
    });
    </script>

(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.

I agree it makes sense in your case - but I'm thinking about complex tables with data, utilizing things like YUI DataTable and JavaScript date formatting for configurability. In that case things aren't as clear cut: I design my application around YUI widgets and then have to think about how it will degrade.

> I design my application around YUI widgets and then have to think about how it will degrade.

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.

Ok, so your answer to my question would be: it is better to design for graceful degradation (progressive enhancement), because one keeps more options open for the future, rather than buying into one complex framework.

Thanks -- I don't necessarily agree, but it is a good answer and a valid point of view.

A lot of the decisions around this depend on what your app is doing. We are building a profiles section to our site with typical social networking features. We didn't provision at all for non-js because a) you need js to even get to the app and b) the director of engineering is an incompetent wanker and has no experience building web apps.

Normally, 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...

I don't; but that's because i mainly develop intranet websites.

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.

Testing. I like to design/build my sites with graceful degradation so I can easily script testing (what can I say, I'm a barebones type of dev).

Reply on news.ycombinator.com