Gone are the days when producing a Web page simply involved writing some HTML code or painting a screen using Microsoft's Frontpage Web design tool. These days, with the Internet going into e-commerce overdrive everyone wants dynamic Web experiences. Scripting has taken a quantum leap.
There are two main categories of scripting language - either client or server-based. They are designed to describe attributes and functions that can be interpreted by browsers to produce a Web page.
Client-side Web scripting started off with hypertext markup language (HTML), which was a static scripting language used purely to describe how a page would look. You can use HTML, for example, to position a headline, and decide which colour it will be.
HTML has come a long way since it was first developed as the basis for the World Wide Web at the start of the 1990s. The World Wide Web Consortium (W3C), the industry body that ratifies some Internet standards, has released version 4.0 of the technology.
VBScript was designed by Microsoft and is a scripting version of its Visual Basic programming language. The problem with the technology is that although it offers great functionality (it is also used in Microsoft Office to customise applications) it is only understood by Microsoft Internet Explorer.
The row over browsers, however, combined with the proliferation of different client devices such as WAP phones, has led to a slow departure from client-side scripting in favour of server-side scripting. Processing everything on the server means that you can give everyone a similar experience of your Web site, while making allowances for different display types.
One of the first scripting interfaces for the server was the common gateway interface (CGI), which enables applications to interpret scripting languages, carrying out different functions as a result. Perl is one of the most common languages used to write to CGI, although this language is hardly intuitive to use.
Microsoft developed active server pages (.asp) as a means of taking inputs from a Web page (from a form, for example) and processing them so that they can interact with objects on the server. This means the input could be used to look up a database, for example. Once the processing has been completed the active server page can then take the output and render it into HTML for display in the browser.
Sun Microsystems responded with Java server pages (JSP) another scripting language that differs because the scripts are compiled and loaded as servlets - small programs sitting on the Web server. Compiled programs are generally faster than interpreted ones, so JSP applications can provide performance advantages (see box above).
According to documentation from software development company Rational, most of an application's business logic should not be held in a scripted page. Rather, it should be held in the business objects that the page interacts with. The server-side scripted page should essentially be the way for the browser to talk to a server-based program.
One of the biggest steps when moving from a static environment to a server-side scripted environment is knowing how the scripts will interact with the middle tier, which contains all of the complicated programming logic that drives the application.
This means that you must have a thorough understanding of the technical architecture of the application, and it also means that if the application changes, the scripting must be regression tested - tested with the new code - to make sure that it still works properly.
One advantage to server-side and client-side scripts is that they are easy to implement. Rather than having to learn a complicated language like C++ or Java you can pick up much scripting functionality in the course of a few days.
But don't let the ease of implementation tempt you into undisciplined development. You still need to observe conventional procedures and safety measures when changing your code.
Next week: Danny Bradbury looks at browser wars and their aftermath.
Learn your lines - a guide to Web scripts
with its Internet information server [IIS]. Scripted pages sit on the Web server and provide an interpreted interface between the browser and the back-end application.