http://www.developer.com/

Back to article

Keeping Up With The Ajax Trend


November 9, 2005

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

JavaScript Debugging

Now that JavaScript-based applications are becoming more complicated and powerful, it is important to have better debugging methods than the traditional alert()s that seem to be commonly used. Most programming languages have very powerful debuggers built for working with them, but because JavaScript has usually been reserved for short, simple tasks, there has been little need for a powerful debugging environment. There are a number of good debugging tools available however, and they are seeing much more attention now that the Ajax movement is in full swing.

In the Mozilla browser suite, there is a debugging interface provided via XPCOM and an excellent debugger has been built on top of that interface. The debugger is called Venkman [3][4], and as it is written in XUL and JavaScript, it works on any platform that the Mozilla browser or Firefox work on. With Venkman, you can step through your code and watch and modify the variables, just as you would with any debugger. You also can include special comments in your code to set breakpoints, or you can use the debugger statement in the JavaScript code to trigger the debugger, or to log debugging messages. The benefit to using the comments is that the browser will only interpret the comments when the debugger is running; otherwise, it will ignore them, as will any other browser. Leaving debugging comments in production code is obviously not recommended, but having the debugging statements not break the page if it is run in a different browser is definitely of value.



Click here for a larger image.

Venkman JavaScript Debugger

Microsoft Visual Studio also includes a facility for debugging client-side JavaScript. The Microsoft Script [5] debugger provides all of the same functionality as the regular debugger, and Microsoft also offers a standalone version of the Script Debugger for developers who don't have Visual Studio.



Click here for a larger image.

Microsoft Script Debugger

DOM Debugging

As pages get more complicated, and elements become dynamic objects which are created, manipulated, and destroyed on the fly, Web developers need powerful tools to inspect the state of a page in the browser. A number of very good tools have emerged for looking at the current DOM for the page being displayed. Firefox ships with an extension called the DOM Inspector that provides a user interface for looking at the DOM for a page as a tree, allowing the developer to view the attributes and values for all of the nodes in the DOM. Microsoft recently released a similar tool that combines functionality similar to the Firefox DOM Inspector with another powerful Firefox extension, the Web Developer Toolbar, to create a very handy tool for inspecting the DOM. Another handy lightweight tool for quick debugging is the Mouse Over DOM Inspector [6], which is a bookmarklet [7] that is essentially a snippet of JavaScript that can be loaded into the current page in the browser to allow a developer to inspect the various elements in the page by simply moving their mouse over them.



Click here for a larger image.

Microsoft Developer Toolbar for Internet Explorer



Click here for a larger image.

Mouse Over DOM Inspector

Looking Ahead

As the Ajax trend continues to build momentum, new technologies are going to enter into the fray, and it is important to keep up with useful innovations. As more business logic is moved from the server applications into the client applications, Web developers are going to have to be smarter about how they implement the client Web applications. JavaScript has been mainly used for scripting and enhancing Web pages with special effects, but now it is being used to build real programs, and so it is important that the principles of general software design and implementation be applied now to programs built with JavaScript. Web developers can no longer throw together a few scripts into a page and call it a day; they need to start designing and building robust applications. Fortunately, some tools are already available to assist in incorporating object oriented programming, and other methodologies from the software world into Web applications. An excellent resource for more advanced JavaScript techniques is Douglas Crockford's site [8].

Regardless of what new technologies come and go, the fact remains that more and more intelligence is being moved from the server side of things to the client side. Traditionally, the real processing power happened on the Web server, and the client acted as a means to gather and display information. Now with the Ajax trend, and the tendency towards rich Internet applications, we are looking at a change in the way that Web developers have to work. The separation between the client and server is becoming more complicated, and so a new breed of Web developer that can understand the entire life cycle of the Web application, from both the client and server perspective, will emerge from the dust and the true vision of the Web 2.0 movement will slowly be realized.

References

  1. Introducing Fiddler: http://www.fiddlertool.com/fiddler/
  2. Immunity: Free Software: http://www.immunitysec.com/resources-freesoftware.shtml
  3. Venkman Homepage: http://www.mozilla.org/projects/venkman/
  4. Learning the JavaScript debugger Venkman: http://www.svendtofte.com/code/learning_venkman/
  5. Scripting Debugging in Internet Explorer: http://blogs.msdn.com/ie/archive/2004/10/26/247912.aspx
  6. Mouse Over DOM Inspector: http://slayeroffice.com/tools/modi/v2.0/modi_help.html
  7. Web Development Bookmarklets: http://www.squarefree.com/bookmarklets/webdevel.html
  8. JavaScript: The World's Most Misunderstood Programming Language: http://www.crockford.com/javascript/javascript.html

About the Author

Jordan Frank is a hybrid software engineer and hacker who has been working with the Internet in various shapes and forms since the early days of ISPs in the mid 90s. He is a lead developer at www.ebusinessapps.com and is an expert in rich Internet applications, AJAX, Service Oriented Architectures, and security. Jordan maintains a blog at http://blogs.ebusiness-apps.com/jordan/.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date