Client Side

It should come as little surprise that the most fancy effects are usually done with scripts written to run in the visitor's browser. This is common sense; since the browser can respond immediately to the users key presses, mouse movements and clicks. Client side scripts are not all special effects however; some can be functional, providing a way to check form input for validity before sending the data to the server.

One of the major problems with any client side scripting is that it is browser dependant. Not only does your visitors have to have scripting enabled, but also some scripts will break in browsers that do not support the object or method that scripts use.

Broken scripts do not have to be a problem if the output is purely for show, but when form submission is dependant on the browser's ability to check the data before sending it, it can be very frustrating for visitors who get "stuck" as a result.

Ideas of when to use client side scripts.

* Complimentary form pre-processing (should not be relied upon!)
* To get data about the user's screen or browser.
* Online games.
* Customising the display (without reloading the page)

Server Side

Server side scripts are friendlier on the visitor; after all, the server is doing all the work and so it doesn't matter so much what browser they are using. This allows for transparent browser sniffing, by detecting the type of browser on the server side, the script can output a particular version of the page (for example to cope with browser incompatibilities) and the visitor would never have to know the difference.

Another advantage of server side scripts is that they can have access to files and databases that would not normally be available to a visitor (as well as the client side scripts). This makes them more flexible in the way they use and access various data sources, as well as being more secure in the sense that the data sources do not need to be web accessible and so exposed.

Finally, server side scripts can be written in a much wider variety of languages than their client side counterparts. PHP, Perl, VBScript, PerlScript, Python, C++, Java and JScript to name but a few. Of course, which language you choose to script in will depend on your server configuration.

Ideas for when to use server side scripts.

* Password protection.
* Browser sniffing/customisation.
* Form processing.
* Building and displaying pages created from a database.

There one more scripting in the world,

Remote Scripting

There is a third kind of scripting which makes use of both client and server side technologies. Remote scripting takes the best of both worlds, the speed of client side scripts with the flexibility of server side code; however it also creates its own problems because of the way it works.

Remote scripting works by allowing a client side script access to server side functions, with the functions being processed by the server. This allows client side code to use scripting technologies that wouldn't normally be available to them, while also calling server generated responses without the need to refresh the page.

Unfortunately the browser restrictions of the client side still apply. Microsoft's version of remote scripting uses Java for its functionality, which is quite ironic seeing how Windows XP doesn't come out of the box with Java support! There is also another JavaScript version of remote scripting that has been developed, which it could be argued now has a wider "active window of availability" than the Microsoft version.

__________________
With,
J. Jeyaseelan
Everything Possible