Client-Side Versus Server-Side Scripting

There are various advantages and disadvantages of client-side scripting and server-side scripting. The main advantages of client-side scripting, with scripts such as JavaScript, although JavaScript can be used for server-side scripting (Tmunotein, I (2004)), are performance and usability, whilst the main advantages of server-side scripting are compatibility and complexity.

For client-side scripting, once the content on the web page being viewed has been downloaded into the browser, in processing terms (and hence performance on the client and server) the time taken to see the results of interaction with the script is almost immediate (subject to certain provisos below) as there need not be any further data transfer between the client and the server; the server need not serve this request which, on busy server, can degrade performance and the client need not wait for the server to respond. In addition, as the correct functioning of the client-side script is based on the browser’s compatibility, such scripts can be served from any web server platform and is therefore independent. Correctly functioning client-side scripts add interactivity to the user’s experience due to their immediate responses which also allows page manipulation on-the-fly to suit the user’s needs increasing usability, especially considering that a client-side script can detect whether they are functioning correctly (e.g. if JavaScript is not enabled (Deitel, P. & H. (2010, p198))) and offer an alternative solution, such as HTML.

For server-side scripting, one of the main advantages arises as a result of the client-side disadvantage; browser compatibility. Server side scripts, such as PERL, do not require that the browser has the ability to perform any other functions or have anything enabled to work other than act as a compliant browser that can interpret the mark-up language presented by the server-side script. This ensures that well written server side scripts will work in all browsers, something that the developer cannot be sure of with client-side scripts as the developer does not necessarily know which browser or version is being used (although techniques can be used to establish this, it is not always successful). Server-side scripts are often more complex than those operating on the client side as, by their very nature, they are designed to fulfil many more functional requirements of web sites.

Server-side code execution as a solution to potential virus infections on the client machine greatly depends on the developer and the user protecting themselves. It is well known that infections can spread through the use of scripts embedded into web pages and that many browsers will disable, by default, scripting activities that may carry this threat. Should the developer be unscrupulous (e.g. malware/spyware publisher) it is entirely possible that the ordinary user can be coerced into allowing seemingly innocent scripts to run on the client-side and cause infection however this is outweighed by the potential benefits that scripting provides for the ethical developer. Should client-side scripting be halted then there are also ways that the server-side could be used to push infections at the user and we would lose the performance and usability benefits of web sites, in my opinion, for no good reason.

References

Deitel, P. & H. (2010) Internet & World Wide Web: How To Program (4th Edition). Pearson Prentice Hall.

Tmunotein, I (2004) Javascript: Client-Side and Server-Side JavaScript [Online]. Available at http://www.devarticles.com/c/a/JavaScript/Client-side-and-Server-side-JavaScript/3/ (Accessed 19 September 2010).