From security point of view, server-side scripts are never visible to the browser as these scripts are executes on the server and emit HTML corresponding to user's input to the page.
When the server serves data in a commonly used manner, for example according to the HTTP or FTP protocols, users may have their choice of a number of client programs (most modern web browsers can request and receive data using both of those protocols). In the case of more specialized applications, programmers may write their own server, client, and communications protocol, that can only be used with one another.
Programs that run on a user's local computer without ever sending or receiving data over a network are not considered clients, and so the operations of such programs would not be considered client-side operations.
In the earlier days of the web, server-side scripting was almost exclusively performed by using a combination of C programs, Perl scripts and shell scripts using the Common Gateway Interface (CGI). Those scripts were executed by the operating system, mnemonic coding and the results simply served back by the web server. Nowadays, these and other on-line scripting languages such as ASP and PHP can often be executed directly by the web server itself or by extension modules (e.g. mod_perl or mod php) to the web server. Either form of scripting (i.e., CGI or direct execution) can be used to build up complex multi-page sites, but direct execution usually results in lower overhead due to the lack of calls to external interpreters
Dynamic websites are also sometimes powered by custom web application servers, for example the Python "Base HTTP Server" library, although some may not consider this to be server-side scripting.
Some server-side scripting languages:
Full article ▸