 |
 |
Login / Sign Up |
|
Home >> Articles >> Programming and Scripting >> Client or Server Side?
Author: Rosemarie Wise
Added: December 31, 1969
Views: 2,077
Rating: 7/10
When the web was young, web pages were relatively plain and simple. There were few special effects and little user interaction. How things have changed! In the constant struggle to be noticed sites are trying to woo visitors with special effects and page customizations. Most of these effects and personalisations will be done by a script of some description; which side of the connection (server or client) the script is best suited to will depend on it's purpose.
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.
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.
Conclusion
There is only the one way to ensure that all your scripts will run the way you want them to, and that is to run them on your server. The obvious downside to this is the extra server load of processing the scripts and the extra time it takes your visitors to learn that their input was invalid.
Client side and remote scripting can help with the pre-processing of user input if the browser supports it, but since browser support is not always guaranteed, you should not rely on any client based scripts to do all of your form processing. All your fancy stuff and special effects can be left to your client side scripts, unless you want to ensure that visitors with JavaScript disabled don't miss out; in which case you should complement it with a server side browser sniffer.
More Programming and Scripting Articles
|
|
|
