This is the second in a series of monthly essays on the business implications of Internet technology. Feedback on these essays is highly appreciated. The focus of the essays is on how technology can be applied in business. In addition, I like to think about the implications for the stock prices of companies such as Netscape. July's essay discussed Intranets. For an index of my occasional writing on Web technology and business, going back to July 1994, see Business and Economic Issues.

What is JavaScript on the Server?

To date, most of the focus on JavaScript has been on the client side, meaning that scripts are run by the browser software on the Web user's computer. Danny Goodman, in his excellent book on JavaScript, wrote that

In particular, look to JavaScript for the following kinds of solutions:

• You want your Web page to respond or react directly to user interaction with form elements (input fields, text areas, buttons, radio buttons, checkboxes, selection lists) and hypertext links.

• You want to distribute small collections of database-like information and provide a friendly interface to that data.

• You want data preprocessed on the client before submission to a server.

--Danny Goodman's JavaScript Handbook, p. 14

Finally, server-side JavaScript allows you to protect your code. Client-side JavaScript is sitting out there for anyone to copy, subject to whatever protection copyright law provides. If you have something that is proprietary, you will feel more comfortable keeping the code on the server side.

Dynamic Processing with Ubiquity

Most users do not have the latest version of Netscape, they do not use plug-ins, and they do not respond to sites that say "best viewed with. . ." by downloading the necessary software. They respond by getting ticked off and going elsewhere. As a someone in the banking industry put it, "People want to get information, not download browsers."

The way to address this trade-off is to put the dynamic elements of a Web site onto the server. Such a site can be used by everyone, including people without the latest version of browser software. In an interview in Wired this past winter, Steve Jobs called this "ubiquity," and he argued that the Web today needs ubiquity more than enhanced capabilities.

Jobs was referring to ubiquity from a user perspective, but there also is an issue from a developer perspective. If you are a Web site developer and want to provide dynamic capabilities to all users, until recently you had to master programming in CGI and Perl.

JavaScript on the server side is a substitute for CGI/Perl that has these advantages:

• JavaScript has predefined objects and methods that directly address the features of HTML documents
• JavaScript is easier to learn for the inexperienced programmer.
• JavaScript is object oriented. By taking advantage of this, the experienced programmer can write code that is much easier to maintain.

Site Maintenance

For example, you may have had a site up and running for months, and then you realize that you would like to put something at the bottom of every page: a copyright notice, a link to a feedback page, a menu, or some combination of these. Do you go back and edit the pages one by one? The really horrifying thought is that you may want to change the footer a number of times, so that you have to go through the editing process repeatedly.

With JavaScript on the server side, you can create a footer and use the script to send the footer to every page. Then, when you want to change the footer, you can change it in one place and have that change reflected in all pages.

There are other tools that help to automate site maintenance. See Web compare for more information. However, because all of these tools, including server-side JavaScript, involve "compiling" your Web site, choosing one represents a commitment. Because of indecisiveness, I have not used any of these yet on The Homebuyer's Fair. As a result, we suffer from inconsistencies, broken links, lack of search tools, etc. However, I am getting ready to take the plunge and correct all that.

For site maintenance, I am looking for a combination of functionality and flexibility. Microsoft Frontpage and its server extensions provide strong functionality. The trade-off, however, is that these products become very difficult, if not impossible, to use when you want to do something that is outside of what their standard "wizards" and "bots" are designed to handle. I view Frontpage as a sort of benevolent dictator--willing to take care of a lot of my needs in exchange for giving up my freedom.

JavaScript on the server side seems to me to offer the maintenance capabilities that I want without stifling my creativity. My guess is that many other Web site owners will feel this way, and that this makes server-side JavaScript an important tool.

Netscape's secret weapon

As noted in the previous section, choosing a Web server means making a commitment to how your Web site will be "compiled." For many people, Microsoft's servers/compilers will have more appeal, because of ease of use or compatibility with Microsoft applications that they want to serve on the Web. For the rest of us, the main advantage that Netscape seems to have is JavaScript on the server side.

When Netscape first went public, I thought that its stock price rose on a speculative bubble. Now, however, I think that they have a viable business. They have created a huge demand on the part of business for servers, and their server has important capabilities that will enable it to command a decent share of the market. I still have not run out and bought any Netscape stock, but I definitely would not short it.

Your insurance rates too high? Better check with The Insurance Professor