Stop treating Ajax as something special

Everyone wants slick applications that use Ajax to reduce page loads and make it feel, well, more application-ny. Of course this is all done in a progressively enhanced way, so the page works just as well without JavaScript.

The problem is, that sometimes, there’s an overhead of the extra work to support the Ajax responders.

If you stop treating Ajax as something special, you’ll find it’s barely any extra work on the server side.


Think of it like this: the Ajax response is the content that drives the page (or parts of it), only without the HTML.

On the server side, you’ve got to collection different datasets to build up the page. The Ajax responders should go through exactly the same route to get that data.

So here’s how you write your Ajax responders compared to how you write the server side code:

  1. The Ajax call should use the same functions.
  2. The Ajax call should use the same controller.
  3. The Ajax call should use the same url.
  4. The Ajax call could use the same query string.

Detecting Ajax

Ajax requests via popular libraries such as YUI, jQuery, Prototype, etc, all include a header that indicates the request is via Ajax:

X-Requested-With: XMLHttpRequest

So you can control the logic flow in the controller by checking if this header is present.

For a practical example, I created (some time ago) a user registration page that includes validation. If the fields are valid, then the registration happen. If any of the fields aren’t valid, it returns the page and the error notices.

The JavaScript enabled version of the page acts in the exact same way, except the page doesn’t reload and validation (i.e. to check for duplicate usernames) is done on the server side.

It reuses the validation module and the same controller as much as possible.

View the demonstration of this in pactise (view the PHP source)

4 Responses to “Stop treating Ajax as something special”

  1. I should comment on Sam’s reply via Twitter:

    @rem Ajax shouldn’t only really be used sparingly, not for everything… has an impact on indexing from Google et al if page blank at start

    By no means am I saying that Ajax should be used sparingly. I think it should be used when it makes the application and/or the experience better. What I am saying is that it shouldn’t require a lot of extra work, and that the queries should be the same as if JavaScript wasn’t enabled – to keep everything nice and consistent.

  2. Well done Remi and I totally agree. In a perfect world every would have JS enabled, but that is not the case so you should design your apps to work in both environments.

  3. This is very true, although actually supporting JavaScript being turned off is becoming less of an issue by the month.

                                       ON                       OFF
    Jan 2008                    95%                      5%
    Jan 2007                    94%                      6%
    Jan 2006                    90%                      10%
  4. @Tom – I was a little late on the reply for this – but here’s my question:

    Do those stats include mobile phones, screenreaders, printers and any other device other than a desktop based browser?

    Obviously not – but hopefully you see my point. It’s important to progressively enhance the page rather than make JavaScript the prerequisite.

    All that said, the point of the post wasn’t that Ajax shouldn’t be used, not at all the point (not saying you’re calling me out to the contrary) – but to say that adding Ajax support on the server side, in a lot of cases, is actually very easy if done correctly.

Leave a Reply
Not required

CODE: Please escape code and wrap in <pre><code>, doing so will automatically syntax highlight