How to build Graceful Degradation AJAX web page?

Question

I want to build web page with "Graceful Degradation". That is, the web page functions even javascript is disabled. Now I have to make design decision on the format of AJAX response.

If javascript is disabled, each HTTP request to server will generate HTML as response. The browser refreshes with the returned HTML. That's fine.

If javascript is enabled, each AJAX HTTP request to server will generate ... well, JSON or HTML.

If it is HTML, it is easy to implement. Just have javascript to replace part of page with the returned HTML. And, in server side, not much code change is needed.

If it is JSON, then I have to implement JSON-to-html logic in javascript again which is almost duplicate of server side logic. Duplication is evil. I really don't like it. The benefit is that the bandwidth usage is better than HTML, which brings better performance.

So, what's the best solution to Graceful Degradation? AJAX request better to return JSON or HTML?

Answer 1

IMO, working with HTML brings greater security risks (MITM script injection, etc). Any time saved on "duplication" should really be spent on sanitizing before appending.

JSON can be safely parsed and is usually much more compact, as you say, saving bandwidth.

I know which I'd choose (JSON).

Answer 2

I don't think there can be a 'best solution` for any given situation. Only perhaps, an 'appropriate solution' for a particular one. It really depends on what you are trying to do. What graceful degradation means to me is:

• build a 'good enough' interface that works on as many browsers (desktop and mobile) as possible.
• Unobtrusively add in some scripting (validation methods, interface elements such as tabs and sliders or whatever) that will only be present if the browser the page has loaded in has the features needed to make them work.

Whether to use HTML or JSON in the server response is highly subjective, I often find myself struggling to choose between them. One might argue, for instance that receiving a bunch of key-value pairs from the server and rendering them into an existing select element would mean more code and therefore more time spent coding and more potential bugs. Instead, you could simply request the pre-built select element from the server, and inject it into a container. The logic for building the element already resides on the server, why build it twice, in two different languages.

The other perspective is that JSON minimises bandwidth usage, so it is worth going the extra mile to parse some JSON to build some markup on the client. I find it easy to disagree with that point of view, for a couple of reasons (I am not generalising, don't get me wrong). First of all, many, many webservers are configured to compress/deflate/gzip their output, and many, many browsers accept compressed content. Markup is extremely compressible, as it contains boatloads of redundancy (<strong></strong>). It is therefore reasonable to consider that the size of a JSON response would not be overwhelmingly smaller than a response-with-markup. Secondly, a large dataset could mean a sizable execution time on the client (nasty, nested loops are commonplace - evident in some of the questions that pop up here).

My advice to you is to try to understand the upsides and downsides to each approach, and to leverage that information. You might want to read this:

http://www.quirksmode.org/blog/archives/2005/12/the_ajax_respon.html