November 26, 2014
Hot Topics:

Keeping Up With The Ajax Trend

  • November 9, 2005
  • By Jordan Frank
  • Send Email »
  • More Articles »

Does Ajax mean the evolution of a new breed of Web developer?

2005 has definitely been one of the most exciting years in the Web development world. It has been said on a number of occasions, by some very influential people, that the Web as we know it is undergoing a significant change. Ajax is finally getting the attention that it deserves, and generating a lot of hype in the process. The term Ajax was coined to describe the new Web application design paradigm that is coming about now. Ajax stands for Asynchronous JavaScript and XML, but the term has gone way beyond being a simple acronym for specific technologies, and incorporates all of the technologies that the modern Web, Web 2.0, is being built on. Keeping up with the latest technologies and knowing which ones have technical merit is an increasingly overwhelming task. In the past, the separation between the client and the server, or the Web browser and the Web server, has been clear and distinct. With the current trend towards tighter coupling between the client and the server, the separation between the two entities has become much fuzzier, and so the question has been posed whether Ajax will mean the evolution of a new developer, a combined front-end and server-side developer.

Ajax Defined

Ajax was originally defined as an acronym for Asynchronous JavaScript and XML, but as I've already mentioned, it means much more than just that to most people who use the term. For the purpose of this article, I will define Ajax as a development methodology for creating interactive Web applications. I purposely leave out any references to specific technologies, and focus on the goals of the Ajax movement, which are usability, browser and platform compatibility, standards compliance, and providing the user with a rich, immersive, and therefore enjoyable experience. Any technology that can meet such criteria can therefore fall under the Ajax blanket. The technologies themselves are really just tools to get the job done. So, look at what tools you have at your disposal.

The Usual Suspects

Not all of the Ajax technologies are new; in fact, most of them are not. The traditional Web technologies such as HTML, CSS, and JavaScript are still the most widely used technologies for building Ajax applications. XHTML has begun to replace HTML, because it prescribes a strict XML format for the markup, and therefore allows the pages to be consumed by any XML parser for automated processing. XHTML is also more extensible than HTML, and allows for other XML-based modules such as SVG to be incorporated into the Web page. CSS is still the most prominent technology for defining the presentation of the content defined in the (X)HTML, and browser support for CSS has improved drastically in the last few years, making CSS an essential skill for any Ajax developer.

As with any good Web application, an Ajax application should maintain a clear separation among the content of the page, the rules for presenting the content, and the code that provides for user interaction with the page. In traditional Web applications, all three of these aspects—the content, presentation, and code—are all present in their entirety when the page is initially loaded. What Ajax brings to the table is the ability to make everything dynamic. New content, new presentation rules, and new code can be sent to and from the client, allowing for much more complex Web pages to be created. Instead of having to encapsulate a single set of functionality into a page, and then have the user redirected to a different page when a new set of functionality is required, you simply can load new rules and content into the existing page when it is needed. This creates a far more fluid experience for the end user, because refreshing the entire page is a time-consuming, disorienting experience.

With this new way of doing things comes a whole bunch of new problems. The main problem is with debugging a page where the content, presentation, and code can change as the user interacts with the page. With a traditional page, the code is in a JavaScript file, and when an error occurs, it is relatively easy to track down where in the code the error lies. When the code is sent up over time in fragments, and exists only in the memory of the client's computer, it is a whole different story. Determining what the error is, and recreating the exact steps to reproduce the error is not a straightforward task, and then determining the source of the buggy code can be very tricky. The same is true for the presentation and the content aspects of the page as well. If there is a problem with the appearance of the page, it is not as simple as going through the HTML and CSS code for the page, because the actual data that is being rendered may be drastically different from the original data. Therefore, a new set of debugging tools and techniques are needed to work with Ajax applications. Fortunately, a number of tools currently exist, and are mature enough to be really useful for solving the problems that one would encounter when creating an Ajax application.

Keeping an Eye on the Wire

Tools for Ajax Development

XMLHttp Debugging

  • Microsoft Fiddler
  • Spike Proxy

JavaScript Debugging

  • Venkman
  • Microsoft Script Debugger

DOM Debugging

  • Firefox DOM Inspector
  • Microsoft Web Developer Toolbar
  • Mouse Over DOM Inspector

One type of tool that has always been of some value for debugging Web applications, but is now vital for Ajax applications, is the HTTP proxy. Ajax applications consist of a client part that exists in the Web browser, and a server part that exists on a Web server, and the two communicate using the HTTP protocol. Being able to listen in on this communication is vital to debugging an Ajax application, and there are a number of tools to do so. Any HTTP proxy will let you observe the traffic, but there are some proxies that have been specially designed for debugging web applications. One such proxy is the Fiddler HTTP Debugger [1]. Fiddler HTTP Debugger sits between the web browser and the web server, intercepting the requests and responses. The tool allows you not only to view the contents of the requests and responses, but to alter the contents. You can manually alter the contents of either the requests or responses, or you can use the built in JScript .NET event-handling engine to add in automated rules for altering the data. Fiddler has a rich API, and is extremely extensible, and so it should be a part of any Ajax developer's toolkit, if they use Windows of course. There are also many open source HTTP Proxies, such as Spike Proxy [2], but Fiddler’s tight integration with Internet Explorer makes it very useful.



Click here for a larger image.

Microsoft Fiddler HTTP Debugger





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel