I kept a list of a few major sites that have been bombing for me with JavaScript errors just today in the last few hours since I decided to write this up:

• Hawaiian Airlines
• Expedia
• Amazon's MP3 Download Site
• Facebook (Email app)
• Musician's Friend Checkout site
• Authorize.NET's Admin interface
• American Express Bill Payment
• Yahoo - certain news stories of the portal home page

And here are a few more non-high visibility ones (all today):

• PInvoke.NET
• Maui Weather Today
• Nova Savings Bank
• Bank of Hawaii

It's amazing to see errors so prominently in major online applications and not just in some offbeat obscure areas of Web sites. As more and more JavaScript is showing up on the client side it's inevitable that there are more errors cropping up, but it's surprising how many of these errors apparently are missed by site designers. Some errors are specific to Internet Explorer, some specific to FireFox, some happen in both, but errors there are plenty of.

I usually am curious as to what the nature of errors are and it seems there are two kinds of prominent errors:

• Load Errors
• DOM Elements are null

Load errors seem to occur because of timing typically. Content's not quite ready because JavaScript is accessing content that's not quite loaded yet. Other errors occur because - well - elements are just null. You look at the source and you find that this or that element that the JavaScript is referencing simply doesn't exist either because it wasn't loaded properly or because the designers simply fucked up.

Ironically most of the bogus code when I've looked at it has something to do with effects and fancy graphics arrangements in the page - shadows, popups, effects. Do we really need to have shadow code update after typing every character at the cost of a constant barrage of errors that page designers hope the browser will just eat and skip over?

But this really begs the question: Are site designers not even bothering testing at least in the two most popular browsers?

Most errors trigger in IE specifically which seems to indicate that more designers are targeting Mozilla, and starting to simply ignore IE's fucked up standard support. Maybe this is what it takes to get Microsoft to clean up IE once and for all. It used to be the other way around in that Microsoft was counting on site designers who wanted to make sure that 98% of the browsers out there work with their sites and other browsers be damned. Now it seems the tide is actually going the other way with more sites failing with IE and working with more standards compliant browsers, regardless of the fact that Microsoft still holds well over 80% of the browser share. Ironic, ain't it?

I's pretty frustrating to see so much bad Web code out there so prominently displayed for general consumption. To be fair though all of the errors I've run into are non-fatal errors. If ignored, pages continue to run apparently unencumbered. I guess that almost makes it more frustrating: what a lame piece of code it must be, if it isn't even missed if it doesn't fire? <g>

I'm railing in futility against this phenomenon because I happen to run frequently with IE and script debugging enabled. IE maddingly pops up a modal debugger dialog on every error:

If I abort the error the page usually continues to load and even work Ok despite the error, but some errors (like the one on Facebook's email message editor) apparently triggers on repeating events like a keypress or hover or mouseclick and I end up stuck on the page and have to kill IE. A modal dialog for the error is a killer in this scenario.

IE really needs a better way to deal with error handling - you have two choices: ignore errors altogether and show a completely worthless warning icon with incomplete error popup for the first error. Or you can go the full Script Debugging (Tools | Options | Advanced) route that pops up the modal blocking dialog on each error. For day to day browsing it would seem ideal to turn off script debugging, but then I use the debugger all day while working in Visual Studio for debugging my own JavaScript/Ajax code and I rarely turn off this option.

I know what you're going to say - don't use IE. Use FireFox or Opera which have better error handling and I do use FireFox most of the time. Firefox mercifully eats JavaScript errors and never throws up a modal dialog. But while  FireBug for FireFox is very useful and cool for debugging on FireFox, it doesn't always work in all scenarios for debugging especially when debugging document (top) level script code. In addition, it's often necessary to debug IE specific issues inside of IE. And if you work in VS.NET the script debugging in VS 2008 is actually useful and often easier to work through than with FireBug in deep debugging scenarios when you need to inspect lots of objects and look up the call stack. You can't completely get away from not debugging in IE after all...

But, hey maybe those fancy Web Designers skip that step - they don't test for IE right? <g>

The errors I've been seeing though are hardly specific to IE though - some also show up in FireFox although FireFox in combination with FireBug certainly makes it much nicer to review the errors with an icon in the browser's statusbar and a quick access list to jump to the errors or at the very least be aware of the errors on the page.

FireBug however doesn't let you stop on an error and step into the code at the error (even as an option) either which on occasion is useful.

In the end I use FireBug for most of my debugging, IE for IE specific debugging and some heavy debugging scenarios where I need to step through lots of code - it's a lot of back and forth and I wish I could stick to one environment but it seems that's just not possible given browser DOM differences.

Ultimately though JavaScript error handling in browsers is pretty arcane. The actual JavaScript behavior is to ignore the error and abort the current block of code that's executing, but other code that follows outside of this block will continue to execute which can often result in less than accurate results and very unpredictable behavior. Trying to track down even errors in JavaScript event code is an excercise in sleuthing supreme as you get to back step through events several levels back to see where a failure occured.

It's no wonder there's so much bad JavaScript code out there - the tools are lacking.

Plain old HTML apps may have been clanky and conservative but they just worked. Now there's a lot of crap being introduced that adds little value, except try to feed our deficit attention spans and in the process make our lives more difficult. I'm all for fancier user interfaces and making applications more interactive and easy on the eyes, but when it comes to usability my first interest is that the application works! Everything else is secondary by a long shot.

There's little we can do with other sites. But we as developers ourselves can do the best we can with our own applications and not contribute to the problem. It's not always easy because JavaScript is inherently a runtime error detection environment. Let's ensure our apps at least  don't bomb by testing at least with the two mainstream browsers. That's the least we can do for our users, no?

So, is this sort of thing happening to you as well frequently? Are you running with debugging features off or are you too suffering through dialogs and error displays on common Web pages?