JavaScript Application Cookbook

Basic JavaScript Programming Strategy

Whenever you build an application, JavaScript or not, it is in your best interest to have a strategy. This helps organize your thoughts and code and also speeds the development and debugging process. There are scores of worthy publications that get down to the nitty-gritty of step-by-step application design, and you’ll probably want to adopt a strategy that works best for you. So I won’t spend too much time here. Keeping the following things in mind, however, before, during, and after you code your way between the <SCRIPT></SCRIPT> tags will surely save you some headaches. It’s pretty simple: just answer what?, who?, and how?

What Are the Application Features?

First, what is the application going to do? Be as specific as possible. What will the application not offer? Suppose you want to develop an HTML form to send email. Consider these questions.

• How many fields will the form include?

• Will users enter the email address themselves or choose it from a select list?

• Do you want to validate the form input before sending it? If so, what are you going to validate? The message? The email address? Both?

• What happens after the email is sent? Do you want to redirect the user to another page or have nothing happen at all?

This barrage of questions could certainly continue. The good news is that if you take the time to consider such questions, you will have a much better idea of what you want.

Who Is Your Audience?

Identifying who will be using the information is vital for determining the app’s capabilities. Make sure you have precise answers to at least the following questions:

• What browsers will people be using? Netscape Navigator? What versions: 2.x, 3.x, 4.x, or higher?

• Is the application going to be used on the Internet, intranet, or locally on individual computers?

• Can you determine the monitor resolution that most users will have?

• What type of connectivity will most users have? 56K modem? ISDN? Fractional T-1? T-3?

Other than the question about browser type, you might think that these questions have nothing to do with JavaScript. “Connectivity . . . who cares? I don’t need to configure a router to do this stuff.” That’s true. You don’t need to be Cisco-certified. Let’s run through those questions, one by one, though, and see why they are important to you.

The browser issue is arguably the most pressing. In general, the more recent the browser, the more recent the version of JavaScript you can use. For example, if your audience is confined to NN 2.x and MSIE 3.x (though I can’t think why this would be the case), you can automatically rule out image rollovers. The versions of JavaScript and JScript in both browsers don’t support the Image or document.images objects.^[1]

Since most people have upgraded to at least the 4.x version of these browsers, image rollovers are acceptable. But now you have to reckon with dueling object models. That means you have to make your applications cross-browser compatible or write separate applications for each version (which can be a lesson in futility).

Where will the application reside? The Internet, an intranet, or maybe on someone’s PC converted into a kiosk? The answer to this question will in turn provide many more clues to what you can get away with. For example, if the application will run on the Internet, you can rest assured that just about any type of browser imaginable will hit your site and use (or at least try to use) the app. If the application is restricted to an intranet or a local machine, chances are some kind of browser standard is in place. At the time of this writing, I’m doing consulting work for a firm that is one big Microsoft shop. If my intranet code chokes in Navigator, I don’t care; users must have MSIE.

Monitor resolution is another major issue. If you’ve included a table 900 pixels wide on your page, and users only have an 800 × 600 resolution, they’re going to miss out on some of your hard work. Can you count on a fixed resolution for all visitors? If this is for the Internet, your answer is no. If the audience is on an intranet, you might be in luck. Some corporations standardize PC hardware, software, browsers, monitors, and even resolutions.

Connectivity issues also have an effect. Suppose you’ve whipped up a mind-blowing image rollover sequence that would give Steven Spielberg’s movie animations a run for their money (if so, maybe you and I should . . . umm . . . collaborate). Pretty cool, but users with 56K modems could probably go out and see a movie before your code loads all those images. Most users understand that the Net can get bogged down with heavy traffic, but after a minute or so, most will move on to other sites. Take the bandwidth issue into consideration.

How Can You Get Around the Obstacles?

Juggling all of these issues may sound pretty cut and dried, but it’s actually not that simple. You might have no way to accommodate all browser versions, monitor resolutions, or connectivity specs. Now what? How do you keep everybody happy and still wow them with your 500K image rollover extravaganza?

Consider one or more of the approaches I’ve proposed below. Read them all so you can make a better-informed decision.

Try the cross-browser approach

This egalitarian method of “the greatest good for the greatest number” cross-browser coding is probably the most common and arguably the best approach. By the greatest good for the greatest number, I mean that most users probably have MSIE 4.x and NN 4.x. You can scoop up a large web-surfing population if you implement significant browser detection and code your application so that it capitalizes on the common features of the 4.x generation while it accommodates their differences.

Elegantly degrade or change performance

This makes a nice corollary to the cross-browser strategy. For example, if your image rollover script is loaded into an unsupporting browser such as MSIE 3.x, you’re bound to get nasty JavaScript errors. Use browser detection to disable the rollovers for these browsers. By the same token, you might want to load different pages according to monitor resolution.

Aim low

This approach assumes that everyone has NN 2.0 browsers, 640 × 480 screen resolutions, 14.4K modems, and a Pentium 33 MHz. The bad new is that you won’t be able to use anything but JavaScript 1.0. No rollovers, no layers, no regular expressions, and no external technologies (be thankful you can use frames). The good news is: the masses will be able to use your application. Actually, recent changes in JavaScript may make even that untrue. I’m admittedly aiming really low, but it’s not uncommon to shoot for, say, NN 3.x and MSIE 3.x. Obsolescence has its advantages.

Aim high

If your users don’t have MSIE 5.0, assume they’re technological nitwits and not worthy of seeing your application, let alone using it. Now you can code away, accessing the MSIE document object model, event model, data binding, and so on. Of course, that sharply drops the size of your viewing audience and can have long-term effects on your ego.

Offer multiple versions of the same app

If you’re a glutton for punishment, you can write multiple versions of the application , say for example, one for NN, the other for MSIE. This method is definitely for those into monotony, but there is at least one twist that can pay off. Let’s go back to the connectivity issue. Since it’s often impossible to determine what type of bandwidth users have, allow them to choose. A couple of links from the homepage will enable users with T-1 connections to load your image rollover spectacular, or users with modems to view the benign version.

---

^[1] Some MSIE 3.x browsers for the Mac do support image rollovers.