It used to be that when web applications broke down, users would be
presented with a lot of annoying technical gobbledygook about
undeclared variables or invalid database queries. With AJAX, those
asynchronous JavaScript apps intended to make the user experience
better and smoother, the symptoms are often less ugly but more
mysterious. The user clicks a button, and absolutely nothing happens.
Behind the scenes, the browser has dispatched a request and received a
response, but now it is choking on a garbled or unexpected response
that it doesn't know how to respond to.
Whether this error crops up during development, or in production, it's likely to be hard to debug, for a few reasons.
For starters, the history of JavaScript and its implementation in
browsers have conspired to make life hard on developers and software
testers. Sun Microsystems engineer Eric Schrock covers some of this
history in a recent Communications of the ACM article on Debugging AJAX in Production:
The JavaScript language has a curious history. What began as a
simple tool to let Web developers add dynamic elements to otherwise
static Web pages has since evolved into the core of a complex platform
for delivering Web-based applications. In the early days, the
language's ability to handle failure silently was seen as a benefit. If
an image rollover failed, it was better to preserve a seamless Web
experience than to present the user with unsightly error dialogs.
This tolerance of failure has become a central design principle of
modern browsers, where errors are silently logged to a hidden error
console. Even when users are aware of the console, they find only a
modicum of information, under the assumption that scripts are small and
a single message indicating file and line number should be sufficient
to identify the source of a problem.
This assumption no longer holds true, however, as the proliferation
of sophisticated AJAX applications has permanently changed the design
center of the JavaScript environment.
Schrock goes on to propose a few strategies for making JavaScript
code easier to debug in production, despite the fact that the
JavaScript environment doesn't inherently provide a good way of
extracting a stack trace of the system events contributing to a bug. He
shows how to overcome some of JavaScript's limitations by implementing
your own stack trace mechanism and methods for catching program
exceptions.
Another reason AJAX applications in particular are challenging is
that behind-the-scenes nature of the interaction between the browser
and the server. Because the response from the server is passed back in
the background, the response itself is invisible to the user. It's only
once the browser retrieves it parses it, and decides what to do with it
(such as displaying a message or updating part of the web page) that
the user sees anything happen. If that process of parsing the data
fails for some reason, the user sees nothing except perhaps a message a
discrete message that there is an error on the page.
The FireBug extension to
FireFox provides several good tools for debugging JavaScript, at least
as it's interpreted in the FireFox environment. Although you can get
some basic information about JavaScript errors from FireFox's built-in
error console, FireBug makes it easier for you to see those errors in
context of where they appear in your code. Maybe more importantly,
FireBug tracks the network traffic that goes back and forth between
browser and server, including both ordinary GETs and POSTs and AJAX
traffic. In other words, it lets you see exactly what your AJAX routine
posted and what the server returned. For example, the return data was
supposed to be JSON encoded, and it actually came back with some other
unexpected output (such as a database error message), Firebug will let
you in on the secret of why your response handler was unable to work
with that output.
Knowing the input can be equally important. Just this morning, I was puzzling over an AJAX app that was supposed to pass a date to a server in the database input format '2010-5-1' and couldn't figure out why it wasn't working. Turned out the JavaScript interpreter was trying to handle that string as a mathematical equation, as in 2010 minus 5 minus 1 equals 2004. So the data actually passed to the server was 2004, and the database was barfing on that as a date.
Jan Odvarko, one of the Firebug developers, has a good blog post on Introduction to Firebug: Net Panel, which documents those network functions.
The Yahoo User Interface Blog also has an article on Production JavaScript Debugging,
focusing on debugging JavaScript code that has somehow developed
problems in production that weren't detected during development and
testing. In order to test JavaScript tweaks and fixes in something as
close to the real production environment as possible - but without
deploying untested code - Yahoo front-end engineer Nicholas C. Zakas
recommends working with a free Microsoft tool called Fiddler, a debugging HTTP proxy.
As you might expect, Fiddler works well with Internet Explorer and
other Internet-connected Microsoft software, but you can also configure
Firefox and other browsers to use Fiddler as their proxy to the
Internet, which allows it to observe all traffic passing between client
and server.
So this is another way of getting insight into your AJAX
interactions, but Zakas says where he has really found it useful is for
performing a sort of slight-of-hand. He configures Fiddler to filter
for requests for a JavaScript file that's causing him problems and
substitute a copy of the file he has stored on his own computer. So
when he tests whatever changes he is making, he is downloading the
exact same page from the exact same server, and the only thing that's
different are the changes he is making locally as he debugs and refines
the code.
Yahoo also deploys its code in a stripped-down format, with all
comments and extra spaces removed, as a way to save bandwidth. So
before he starts debugging, he also reformats the code to be easier to
read and comprehend.
Fair to say, there ought to be a better way, and maybe we'll find it eventually.
Only registered users can write comments.
Please login or register. |
