This article was originally published in PC Pro and is reproduced with permission.
Many people are rather afraid of scripting, which is hardly surprising as it's such a vast area with a lot to understand. Before you write a script, you have to make two very important choices: which scripting language to use, and whether to run it on the server or client side.
First scripts. These can be run on the client side, executed within the Web browser or the server side, executed by the Web server. In some cases the choice of which side to run is straightforward: for instance, to animate an image as the user moves their mouse around the screen, you have to use client-side scripting. Similarly, to log the users' responses to a form on your site into a database, you'd almost certainly want to use server-side scripting. Other cases, however, aren't so clear cut.
Take a 'widget production' calculator. This has two input fields, the number of widgets required and how quickly they're needed, and it outputs the resulting price per widget. This is a calculation that could run on either the server or the client, and each side has various theoretical pros and cons. Client-side scripting requires the program that calculates the widget cost to be downloaded into the browser, and if this calculation is very complex this could take some time. A server-side calculator, however, only needs to download a standard HTML form for the inputs. On the other hand, once the two input values have been typed in, a client-based script would be able to provide the answer without further Net access, whereas a server-based version has to reload the page with the answer inserted.
Forget the theory, though; experience shows there are two overwhelming reasons why you should keep scripts on the server side where possible. First, there's the matter of code security. With client-side scripting, your widget production cost algorithm is available for all, including your competitors, to see by simply selecting 'View Source'. Do you really want other widget producers to know how you calculate your widget pricing? Probably not.
The second reason is browser compatibility. Not all Web browsers support scripting, and even when using suitable browsers like Internet Explorer (IE) or Netscape, some Web users experience abnormally high paranoia levels and turn scripting off. Keeping the scripts on the server side ensures anyone can use your widget calculator, from people running the latest version of Netscape Communicator, right through to folk accessing the Web from a Psion Organiser or other Web-enabled PDA.
Mind your language
Choosing a scripting language is slightly more complicated. When writing server-side scripts you may be able to use scripting facilities integrated into the server, like Microsoft's Active Scripting in IIS or Netscape's server-side JavaScript. Or there's a traditional CGI scripting language, the most popular of which is Perl.
At first Perl seems to be the obvious choice, as there's plenty of example and library code available, and a degree of cross-platform portability. In reality, something like Microsoft's Active Scripting has a distinct advantage in being far more closely integrated into the server's environment, which enables you to build a more feature-rich site. Also, we've found that the most common implementation of Perl for NT (by Activeware) has serious stability problems, especially when run on multiprocessor servers. Okay, all software has bugs, but we first reported this multiprocessor problem to Activeware more than a year ago, and there's still no sign of them even acknowledging it, let alone fixing it. A similar problem with ASP scripting was reported to Microsoft and got fixed within two weeks. It's also important to bear in mind that Microsoft's ASP and Netscape's server-side JavaScript are both vendor-supported technologies, whereas most Perl implementations aren't.
Another nice feature of Active Scripting is that the HTML and scripting code are mixed in the same file. Consider the example in Listing one (see Code). This script prints the text 'PC Pro' in fonts that increase in size from two to seven. This is a normal HTML page with three small bits of VBscript embedded between the <% and %> tags. Listing two (see Code) shows how you can do the same thing in Perl.
<HTML>
<HEAD>
<TITLE>Text with incremental size increase</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF>
<% for i = 2 to 7 %>
<FONT SIZE=<%= i %>>PC Pro</FONT><BR>
<% next %>
<BR>
</BODY>
</HTML>In Perl things are the other way round; the HTML page is embedded within the script, inside 'print' statements, and we have to take care of details like Mime type headers, line breaks and the correct use of semi-colons. It should be obvious even from this simple example that Active Scripting provides a cleaner solution, easier to develop and maintain.
#!/usr/bin/perl
print "Content-type: text/html\n";
print "\n";
print "<HTML>\n";
print "<HEAD>\n";
print "<TITLE>Text with incremental size increase\n";
print "</HEAD>\n";
print "<BODY BGCOLOR=#FFFFFF>\n";
for ($i = 2; $index <= 7; $i++) {
print "<FONT SIZE="; print $I; print ">PC Pro</FONT><BR>\n";
}
print "<BR>\n";
print "</BODY>\n";
print "</HTML>\n";Client reliant
On the client side, the choice is between JavasScript/JScript and VB Script. JavaScript has the advantage that it's supported by both IE and Netscape, or rather it should have that advantage: in truth there are certain things that work in IE's JScript but not in Netscape's JavaScript and vice versa. Then differences between versions of each browser muddy the waters even more. Take the code in Listing three (see Code) for example. Manipulating an object in toolbar.asp from some JavaScript in toc.asp will work just fine in Netscape 3 but fails miserably in Netscape 4. Why? Because 'toolbar' becomes a reserved property name in Netscape 4! Who knows how many sites there are out there with a now-broken frame called 'toolbar'.
<frameset rows="70, *">
<frame name="toolbar" src="toolbar.asp" scrolling="NO" frameborder="0" framespacing="0">
<frameset cols="30%, *">
<frame name="toc" src="toc.asp" frameborder="0" framespacing="0">
<frame name="mainbody" src="main.asp" frameborder="0" framespacing="0">
</frameset>
</frameset>
Only IE supports VBScript, which makes it fine for intranet sites that distribute a single target browser, but pretty useless for commercial Web sites. Having said that, it's amazing how many Web sites are designed to work only with Netscape (or IE), which from a marketing point of view is crazy! Imagine a company producing a TV commercial that could only be viewed on Sony sets?
Microsoft has recently confused things even more with the introduction of Scriptlets. At first this technology looks interesting, but scrape away the gloss and you'll see that scriptlets are little more than client-side include files, and at the moment they're only supported by IE 4. To continue the TV ad analogy, scriptlets restrict the audience not just to people with Sony sets, but to those with a particular model!
To summarise our advice on scripting: 1) Keep it on the server wherever possible. 2) On the server, try to use integrated and supported scripting facilities. 3) For client scripting use JavaScript, but design your scripts to work with all the common browsers, and keep testing those scripts as new browsers are released.
All articles Copyright CST Group Limited ©1997-2024
Let's Talk
Whether you have a new or existing project, we’d love to hear from you.
Our experienced team thrive on problem solving and working with your business goals in mind.