Ajax: Cool Tool or Problematic Platform?
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.
Why? Because Ajax lets you send and retrieve information from a database without reloading an HTML page.
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.
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.
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.