
Ask HN: do you design websites so that they work without JavaScript? - jwr
I know it may seem like a controversial thing to ask, but I'm asking seriously.<p>When you design a web application today, do you plan for graceful degradation if someone has JavaScript turned off? If so, why?<p>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%.<p>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.<p>So what are your reasons for graceful degradation?
======
zepolen
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.

~~~
jwr
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.

~~~
zepolen
> 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.

~~~
jwr
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.

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

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

------
derby
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).

