There and Back Again

Deciding What AJAX Programming Style to Use

In my AJAX book, Understanding AJAX, I spend a lot of time talking about the various programming styles you can use with AJAX. Looking back at the chapter it seems to me there are 2 major styles of programming and large number of varitions depending on what data encodings were using, and where the bulk of our programming actually happens.

Looking at my own day to day development I tend to fall into a couple main approaches.

  • AJAX page chunks (sending standard GET/POST requests, and updating part of the page by innerHTMLing in the respose)
  • RPC using generated proxies
  • Widgeted AJAX using RPC in the background

Now each of these approaches has its advantages and disadvantages. AJAX page chunks are easy to understand, on the PHP side im generating HTML using a standard MVC framework, and I can just turn off my outer wrapper for the chunks. The disadvantage is that my JavaScript code doesn’t have a lot of power in this approach. I’m skipping full page reloads but I still might be updating a large percentage of the page for a very small change. Its also hard to update disperate parts of a page. To solve this I sometimes find myself returning an array of HTML chunks but this quickly leads to both the PHP and JavaScript sides of the equation getting overly complicated and brittle.

AJAX Page chunks are especially nice when dealing with forms, you just serialize the form to a query string, POST it to the PHP side and return the updated form, replacing the innerHTML of the forms parent with an updated form. I consider page chunks to be my first option, they make it easy to use a single code base to support AJAX and non-AJAX operation, and most importantly are an easy concept for new developers to pick up. It also leverages current skills and keeps the amount of JavaScript down since devlopers are more likely to look towards PHP (or whatever backend lanuage you use) to solve there problems.

RPC style AJAX using generated proxies is very powerful while still being pretty simple. HTML_AJAX makes programming in this style extremly easy to implement. On the PHP side I write a class that becomes the external API to my application. HTML_AJAX covers exporting the API and encoding the data, and on the JavaScript I get a generate proxy that makes that API easy to work with.

Then its time to write a lot of JavaScript code. The biggest benefit of any RPC approach is you have data in your JavaScript not just some HTML. I tend to use an approach like this when i’m building a JavaScript application. It tends towards a more client server model and moves things away from a standard MVC approach. The biggest disadvantage to this approach is the complexity. You end up with huge amounts of JavaScript code, and much smaller amounts of PHP. This wouldn’t be horrible if JavaScript was mature and consistent on all browsers but its not. Plus you can’t trust the client so the PHP code still ends up being larger then you’d like since it has too enforce all the security and integrity rules of the application. But at the end of the day sometimes you need the power.

The last style I use is related to the more standard RPC approaches but I’ll often use it along with AJAX page chunks. With widgeted AJAX I develop a self contained set of HTML and JavaScript code that can be easily integrated into any page. This might be a autocomplete/suggest style dropdown or a live grid. I normally use RPC on the backend inside these widgets since they need actual data but what there using doesn’t really matter. The point of the widget is too make things self contained enough that they can be easily integrated with anything.

Looking at these styles I think each can have it place, but I think my decisions on what to use are more and more driven by simplicity. When looking at a problem whats the simplest solution. The more I use AJAX the more I see that its added complexity is its biggest problem. Like any other programming the simplest solution is usually the best one.

I’d like to hear your thoughts on the matter, what AJAX programming styles do you use and why?

9 thoughts on “Deciding What AJAX Programming Style to Use

  1. Chris Hartjes

    Hey Joshua,

    Until my Javascript skills get to a higher level, I do things the AJAX page chunk way. Things like replacing the form with a thank you message after submitting valid information, click-sortable grids of website statistics. Given the nature of the beast (find a bit of AJAX goodness that someone else created, modify it for your own needs) I think that is probably the default mode for most AJAX work.

    I’m sure at some point I will encounter something I will want to do that will require a lot more Javascript so I will move to more advanced techniques. Not to shill someone else’s book, but “Ajax Design Patterns” shows lots of examples of things that would cause me to break out of the AJAX page chunk mode. I just have to find an excuse to use one.

    I’m curious: does your book cover similar content?

  2. Joshua Eichorn Post author

    Chris:
    I’m not sure if I covered it well enough in this post, but a big part of my point is that the complexity of those other patterns usually means they are worse approaches then just doing page chunks. I find a lot of times I tend to look at a fancy solution first, start implmenting it and then realize im just wasting time. I’m seldom the only person working on a project these days and when I do something complex I’m the only one who can support it, and in many cases understand it. Its not fun to be the choke point on both the backend code and the frontend because of all the AJAX you’ve added.

    My book covers a bunch of different patterns in the example applications that are built. It also shows off a bunch of basic stategies in a more abstract sense. But the books focus isn’t on being a patterns book so you won’t see a lot of the contrast and comparision between the different approaches.

  3. Joshua Eichorn Post author

    Ivo:

    It is an argument for using AJAX page chunks even for things like a live grid. But im trying to stay focused on the development side. One approach might be faster but as long as whatever approach you use is fast enough does relative speed really matter?

  4. Stan

    Josh,
    I’ve been working for a company that writes web-based education software in Java and they’re progressively moving their app over to being more AJAX driven. Unfortunately, the preference there is that we use DOM to make any alterations to the page. We do this even when chunks would save us a lot of time and speed on the browser. Error handling in struts sucks – but the one advantage I’ve had thus far with the way we do it there is returning error objects to the client Javascript and dealing with it there. I’ve not yet seen a clean and easy way of handling errors with chunking. Part of the struggle I’ve been faced with too is that we’re limited to using Prototype and each AJAX call results in a separate action file. Pain in the arsh! Now on the other hand with some non-profit work I do in php I use HTML_AJAX most of the time, there though I use it mostly to trigger events, throwing flags on a database table row – when I do need to handle large blocks of HTML I handle them in chunks.

    Pax,
    – Stan

  5. Laurent

    Hey Stan,

    Just out of curiosity, what kind of web-based education software are you guys making?

  6. Jan Schneider

    I didn’t think about the different AJAX techniques we use before I read your comments. But it’s a nice distinction and we actually use chunks and widgets in DIMP (http://www.horde.org/dimp/). I guess the different methods have been chosen correctly intuitively. We use chunks when changing larger parts of the interface like displaying a message, opening a compose view etc. Widgets are created dynamically from JSON objects or loaded as static HTML chunks and use callbacks to update themselves, e.g. in the folder listings, mailbox views and similar.

  7. Sudeep

    Hi ,

    I have a problem deciding whether to use Ajax for a situation like the whole page has to be refreshed . We are designing a dashboard which gives the status of the clients worldwide with green light indicating that the client is working fine and the red indicating that it has failed ,I need to poll the server for the status every 10 mins and update the dashboard accordingly .It also displays the last response time of each client so the time option also has to be updated .
    Can I use AJAX for this situation .Does it make any difference using AJAX in this case ……….

    Thanks and Regards,
    Sudeep

  8. Joshua Eichorn Post author

    If your reloading the majority of the page, you don’t gain a lot by using AJAX, you could just use a meta refresh tag, or refresh the page using a bit of JS.

    This might be a case where moving just the data that is updated using an RPC style call might make a lot of sense. You get the data and then update your timestamp and change status images using the DOM. Im guessing the your actually only updating maybe 10-20 pieces of data well under 1k where a full page reload might be 20K or 30K. So you could get some huge bandwith savings.

    So too sum it up, if you need to save bandwidth and can make an RPC style approach work then AJAX should work for you.

    If you don’t need to save the bandwidth or you don’t want to mess with RPC AJAX then don’t use AJAX at all just refresh the entire page.