Web addresses no longer end with ".html" - a host of scripting
languages are available to jazz up your pages. Danny Bradbury
offers a guide to .php, .asp and the rest
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.
In the late 1990s HTML spawned dynamic HTML (DHTML). This
language enables the browser to interact with the end-user,
creating pop-up windows and so forth. But DHTML had to compete with
some other client-side scripting languages, in the form of VBScript
and JavaScript.
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.
Much more popular these days is JavaScript, which was released
as part of Netscape's Navigator browser in September 1995.
Microsoft quickly followed with its own implementation, and
unfortunately the two were not initially compatible. The European
Computer Manufacturers Association (ECMA) developed a standard
version in June 1997, and the browsers are now much more in line
with one another.
JavaScript can be used to do multiple things, such as validating
forms on the client, creating animations and changing your
experience of a site according to the time of day, for example.
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.
I learned how to program many features in JavaScript by reading
a book that only took me two days. It is an excellent way to take
advantage of your Web-based application quickly and easily.
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
- Javascript: Client-side scripting language, developed in
1995.
- REXX: A scripting language for IBM mainframes, developed in the
late 1970s. Later versions developed for DOS and Windows.
- TCL: Tool Command Language, used for processing strings and
passing commands to interactive programs.
- ASP: Active server pages. Developed by Microsoft for
use
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.
- JSP: Java server pages. Sun Microsystems' answer to active
server pages. These scripted pages are compiled and run on the
server as small programs called servlets. They do much the same
thing as active server pages.
- PHP: This open source server-side scripting language is
embedded into HTML, much like other scripting languages, and
provides an interface between the browser and the back-end
program.