With a lot of languages, the checks and balances I speak of might be something as straightforward as a compiler. If your code doesn’t compile, you obviously have some issues to which you need to tend. If your role as a developer is in a more institutional setting your code may be subject to a gauntlet of hungry QA engineers, waiting to slap bug slips on your forehead as if you were some sort of heathenish criminal for submitting anything other than flawless code to their domain. While these are both tried and true extremes of probing your semi-colon drenched labors for faulty wiring, as a web developer, I feel we deal with a much more villainous system—multiple web browsers.

If you’ve ever spent any time around a web developer at all, you know what I’m talking about. Get within feet from their office or sit across the coffee shop from their squatting location and you’ll continually hear the phrases “I $@#%* love Microsoft”, “#@$! you Internet Explorer”, and my personal favorite “You’ve got to be kidding me, that’s obviously cached somehow.” And while it’s awfully painful to spend a couple of hours writing your latest piece of JavaScript, only to have IE6 bash it down like a kid at the fair playing the whack-a-mole game, it’s also enlightening; and let’s face it, it keeps us honest.

Case in point. I was working earlier today on a piece of code to handle some visual effects for a OnePress widget. Seeing the end of my task in sight, I decided against retooling my methods that I had so carefully crafted months ago and went down the path of twisting some of my properties to quickly accomplish the task. F5. Firefox works. Perfect. Now for a quick test in Internet Explorer and I’m on my way to the coffee refill station. “#@$! you Internet Explorer!!!”

I let out a nice sigh, the kind I’m sure Rick gets a little restless of hearing when I enter this land of frustration… But after a few minutes of staring at my work and dreading having to go back to square one, I decided that there was indeed a better way to approach my task. I blasted away on my code for the next ten or fifteen minutes, thinking that I may need to break for caffeine sooner than later, but I really wanted to push through. Finally, Ctrl+S and VOILA! I had correctly implemented my ideas and it felt good. I had accomplished my task the right way and all of my test browsers agreed.

Now here’s an awesome case of this system checks and balances pushing me to get things accomplished the way they should’ve been from the get go. Had Internet Explorer not sqwaked at me so violently, I probably would have committed my code, although 100% functional, not completely optimal. At times like this it feels good to have the competency to regroup and make another go at it. I looked at Rick and said, “Man, we web developers really do have a system of checks and balances to go through; but it totally works.”

Building for the web can be tough. Building for web browser can be tough. And that’s why good code prevails. Especially when working with JavaScript, shortcuts are a terrible idea. When you start messing around with DOM element styles and other items that could potentially be browser specific, you can get yourself into a lot of trouble. If you find yourself going down that road, take a quick stretch and think about the other paths. Keep your mind set on making it through the browser gauntlet with what will eventually be the most robust solution.