Chris Peters: Web Developer

AJAX 101 presentation at Spring

Filed under: Programming — Chris Peters, March 23, 2006

SEOMUG Spring BreakRob Gonda introduced AJAX in the first session I attended. No new surprises in the definition for me: a way to use JavaScript to make calls to the server without a full page refresh. Probably the more insightful part was in how to approach using the method and some tools to help out.

Problems and planning

AJAX will more than likely add quite a bit of complexity to your project if you choose to implement it. You need to consider many cases, including what happens if data doesn’t get transmitted properly and the random nature that packets get sent over TCP/IP. The first data you send to the server may not necessarily be the first to reach the server, and the responses aren’t guaranteed to return in the order you intend.

One huge suggestion that Gonda had was to keep your business logic on the server side. Don’t pass your hackable business logic to the client in the form of JavaScript.

There are some new user experience issues involved in developing “client-rich” interfaces that a traditional web developer like myself probably isn’t experienced enough to consider. For example, some AJAX actions aren’t suitable to involve the back button, and some actions may break the back button. Also, because users are used to getting the feedback inherent in waiting for page refreshes, they will still need some sort of feedback along with the asynchronous calls that AJAX introduces.

Tools to get the job done

Gonda suggested using AJAX libraries that take care of many of the cross-browser issues that we developers wouldn’t prefer to think about. The library I’m most interested in checking out it is Gonda’s own ajaxCFC.

In order to debug, the FireBug extension for Firefox looked pretty useful.

Final tips and information

Some quick bullets (some a recap):

  • Plan extensively. Bringing this event model in requires quite a bit more planning and thinking.
  • Don’t write everything in JavaScript. Put your business logic on the server side.
  • Use GZIP to compress your JavaScript output. Most modern browsers understand this.
  • Give progress indicators during the asynchronous calls.
  • Design for error. Ask yourself “What if?” a lot when planning for what could go wrong.

Technorati Tags:

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment