What Ajax Is Not

Ajax is not the be-all and end-all solution to every new application being built for the Web. It is not even something that should be considered as an upgrade to every existing product. Ajax is a great model for building more modern, faster Web 2.0 applications, but only when they are built correctly. Throwing Ajax at every application can create complications, such as accessibility issues, cross-browser compliance nightmares, and requiring more intricate and complex programming to perform simple tasks.I want to make sure this is clear, before everyone gets all gung-ho and throws Ajax everywhere. Ajax is not for everything.

I love the Ajax model of design; I think it brings web applications closer to the capabilities of desktop applications. I also know, somewhat from experience, that Ajax is not the best solution for every project, and that it can sometimes overcomplicate what could have been a simple solution. As you read the rest of this book and you see Ajax solutions that I present to common web design issues, ask yourself whether Ajax is right for you and what you are trying to accomplish. It could fit perfectly, but it could also be the wrong solution for you after all.

Ajax technology can bring a lot to a web site if Ajax is implemented properly and used correctly. This does not mean, however, that even when you use it in a completely justifiable manner it does not contain risks. All new technologies contain risks. More risks are uncovered as more people use the technology and all the glitches and gotchas are flushed out. Many of Ajax's problems are out of the developer's hands. Browsers implement the foundation for Ajax, and developers are at the mercy of browser creators and maintainers when new risks are discovered.

With this knowledge, you will be able to decide whether and when Ajax is right for you. Ajax brought web browser technology to the point that it can be used to create desktop-like applications, but Ajax is not without its little bugs. You should feel comfortable implementing a web application that can avoid these risks, or provide alternatives if necessary.

When the World Wide Web was created and browsers were made to display the content available, life was simple. The browser was meant to interpret the markup sent from the server, and then to display the results to the user. Most of the content was text, and then slowly media began to be used as well. Even so, a web programmer at the time had little to think about when it came to the client (the browser). Eventually, however, content became more complex, and to give developers the means to build better pages, browsers introduced JavaScript. JavaScript is now one of the tools in a developer's toolkit when she's developing a web application.

JavaScript is useful for building any web application, but it is not required. A very serious risk to any application written for a web browser using Ajax is that Ajax needs JavaScript. There is no way around this dependency. As such, if you rely on Ajax to navigate or pull up content on your site, a user's browser must have JavaScript enabled for the site to function properly.

What happens when a user decides JavaScript is a security risk for his browser that he does not want to deal with? His first instinct is to disable all JavaScript from functioning in his browser. Where does this leave you? With a problem, that's where.

To create a site that will work for everyone (even those who disable JavaScript in the browser) you must be prepared to create an alternative version of your site, or the design of the application and the Ajax it uses need to degrade nicely. Throughout this book, I have provided examples that degrade nicely in browsers that have JavaScript enabled. There are some quick tricks that allow Ajax-enabled content to degrade in an eloquent manner.