Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

6 Ajax Rules To Live By

DZone's Guide to

6 Ajax Rules To Live By

· Web Dev Zone
Free Resource

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

Ajax, or Asyncronous Javascript And XML, has been around for a few years now. Web Developers have done some really great things with AJAX, but I've also come across some horrible uses of Ajax. I've coupled together my experience as a Web Programmer and a lowly web user and have come up with six Ajax rules to live by.

Ajax to Enhance, Not to Function

First and foremost, the important part of creating a quality website is making the site work. How? Doesn't matter, as long as the user knows it works. A typical user will even overlook loading speed if the site does what they want it to. That said, do you really want a user to be able to turn off javascript and have your site stop working for them? The one visit your website doesn't work for them, they're not coming back. Make everything works using standard page refreshes first, then come back and Ajaxify your site.

Always Let the User Know What's Going On

There's nothing worse than clicking something and seeing nothing happen for two seconds. Users are used to click and go, or at least click and watch the progress bar move. Remember that Ajax is a relatively new technology — if the user sees nothing happen, they believe your website is broken. I suggest using an unobtrusive message that fades in and out gracefully.

You Did It With Ajax? Cool! Who Cares?

Face it — For most websites, 90+ percent of users don't know what Ajax is or why it's cool. I appreciate a good Ajax script, but does anyone else? Likely not. Unless you have a website geared towards Web Professionals, do your users a favor and hide your "Made Using Ajax" message. I don't care what voodoo magic you use as long as the website functions.

Ajax at the End

Delivering the web project is the number one goal, so add your Ajax functionality toward the end of the project or after the website is done. Sure, Ajax can save a page refresh, but users are used to the old-fashioned way, waiting or not. I can't imagine your customer being satisfied with "It's not done, but look at how this box gets updated without the page being refreshed!" I'll take a working, old-fashioned (actually, standard is probably a better word) website with the promise of Ajax later over a late project any day.

The Security Rules Still Apply

The URL of your Ajax may be hidden in your code so that most users don't see it, but I bet you I can find it. If it can be found, it can be exploited. Don't assume that because you made your web form or page code bulletproof that a user can't manipulate your script. Make sure to scrub the GET and POST variables before doing any Ajax script processing.

Ajax Saves Load Time…But Your Javascript Library Doesn't

Your Ajax code saves a user a page refresh, which allows for the header, footer, and navigation to NOT be reloaded? Cool. Your javascript library is 80kb? Not cool. Be sure to only load your library when needed, and don't add any more code than you absolutely need for the page. Exchanging load times, in this case, isn't efficient or user-friendly.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

Topics:

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}