Ajax: Cool Tool or Problematic Platform?

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Ajax, among other things, is a cleanser, the name of not one but two Greek heroes described by Homer and, of course, it’s a way to make Web sites shine.

Ajax (Asynchronous JavaScript and XML) is not a platform or programming language but the catch-all name given to a set of technologies that, when combined, let you couple Web sites to database systems without the sluggishness of plain old HTML.

Why? Because Ajax lets you send and retrieve information from a database without reloading an HTML page.

By combining HTML, cascading style sheets (CSS), the document object model (DOM — an HTML application programming interface that outlines the logical structure of a page and allows it to be altered), JavaScript, XML and, of course, HTTP headers, Ajax lets designers do most of their work on a single page.

JavaScript is used to collect input, which is sent to the database through HTTP headers. When data is received (often in XML), JavaScript then alters the existing HTML through CSS and the DOM. To end-users, the result is seamless and unmarred by glacially paced page transitions and the Web’s archenemy: waiting.

How you code, test and debug Ajax is beyond our scope here (but there are many books, Web sites, user groups and Web-based instruction just a few keystrokes away). Here, we’ll look at when to use Ajax, when to avoid it and whether it’s worth the work.

The Pros
There was — and still is — a problem with plain, old vanilla HTML. It’s nice for brochureware and coupled with CSS, it can render complex and even elegant designs. But for sites that need to interact with a database, HTML makes the user read a bit, submit a request, wait for a response, wait for the new page to load, then read a bit, submit a request and so on. The “H” in HTML might stand for “hyper” but, truthfully, HTML is slow.

Ajax, of course, gets rid of that slow synchrony. In a nutshell, that’s its biggest plus. It also takes the loosely coupled model of HTML and binds it more tightly to a data source.

As an added perk, merely loading data — and not all the HTML needed to display the data — means your Web site needs less bandwidth. If your Internet service provider bills you by the byte, this means hosting is cheaper.

What’s more, Ajax lets you build graphical user interfaces (GUIs) that mimic desktop applications, giving the user something with which he’s already familiar.

The Cons
But nothing is perfect. First of all, Ajax is complex — at least more complex than brochureware. You’ll need to know HTML and CSS, which is no problem for most designers, but you’ll also need a healthy dose of JavaScript and XML, not to mention a decent knowledge of the DOM. That brings the designer closer to the programmer’s realm, where many graphics gurus fear to tread.

And speaking of JavaScript, remember Microsoft and Mozilla have yet to agree on which form of JavaScript they’ll support. A script that works flawlessly in Internet Explorer might not work in Firefox. Don’t forget the cross-platform issues as you move from Macs to PCs to Linux, all of which support JavaScript in slightly different ways, as well.

If your Web site depends on search engines for traffic, remember that search engines, by and large, won’t read the data in an Ajax application. If you’ve built a gorgeous Ajax interface that lets users load most of your site through a tabbed interface, Google and Yahoo might see only the tabs, leaving the bulk of your content to the unindexed realms that are sometimes referred to as the “hidden web.”

This does not, of course, mean you should hide from Ajax. Whether it works for you depends on what you’re coding, what you’re building and who will use it. In the end, the decision is as unique as every Web site — and Web designer — that makes it.

David Garrett is a Web designer and former IT director, as well as the author of “Herding Chickens: Innovative Techniques in Project Management.” He can be reached at editor (at) certmag (dot) com.

Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|