Client-Side vs Server-Side

No additional tasks are set in this chapter, however it has been included to describe the differences between the client-side and server-side in web development. This may come across as quite a simple concept to some, but it is worth highlighting for anyone not aware of the model.

Client and server side are two areas where our developed code is executed. The client being the end-user’s device (e.g. a desktop/laptop, mobile/tablet or other Internet capable device) and the server being our remote web-servers which have their own computing power.

1. Client-Side

HTML, CSS and JS are all client-side languages which is interpreted and rendered by the end-user’s web browser, e.g. they may be using Google Chrome on a laptop or mobile device, in such case Chrome will be responsible for rendering our site/app on the device. Once our server delivers the response, we no longer have control over them and it is the end-user device’s responsibility to correctly render.

As a result as our users will be using various clients, in development it is worth testing our code with these multiple browsers/devices to ensure they render as we expect. I often test final products with Chrome, Safari, FireFox and Opera, whilst using Apple’s Xcode to simulate iPhone devices (only available on macOS).

Often you will find client’s use outdated devices and browsers, which will have a detrimental impact on your site/app’s appearance and functionality. When offering development services to some agencies (some as recent as last year) they have requested me to implement support Internet Explorer. This is as their customers are not able to install an alternative browser as their company enforces a Device Management policy. In such cases if we don’t want to support IE (or other browsers, e.g. Netscape), although a poor implementation, is that we can display a pop-up/modal to the end-user notifying them that their browser is not supported.

As you’ve used with NPM, we can use Sass, Node.js amongst other advanced languages to build our front-end code. These must be compiled to vanilla HTML, CSS, JS for the browser to be able to interpret and render them.

2. Server-Side

For processing data (or more computing power) we can utilise the server’s capabilities, and in most cases it will provide additional performance over a client device. As we execute the code on our own server, we install all the requirements and dependencies on the server (e.g. PHP, Java, Python and etc.). This enables our code to be executed for the purpose of a response to be returned to the client. As the processing occurs on our server, we have control of the response and we can be confident that all devices (regardless of OS, manufacturer, browser, age and etc.) will receive the same output.

Additionally any server-side programming code we develop is not exposed to our client, the source code is hidden. The client only receives the processed response and this is important when we want to keep parts of our code confidential, such as the API keys as we experienced when working with APIs.

As our server delivers the content/response for our site, we also have access to the client’s details. The details we have access to are the end-user’s IP address, OS, user-agent (e.g. Chrome, Postman, FireFox etc.), the page the user was referred from and etc. We can access all these details using a server-side programming language such as PHP, whereas this information is not available using a client-side language (albeit you could do using Ajax to contact a server).

You may be wondering how are we able to write PHP code on our local machines if it’s a server-side language? By using a LAMP (Linux, Apache, MySQL and PHP) software, this replicates a server environment on our machines so we can develop our code locally before we publish them online. In our case, we’re using XAMPP.

3. Summary

Utilising a server-side language does provide additional capabilities, such as integrating with databases, defining URL routes, controlling who has access to certain resources and etc. However the downside to using a server-side language is that a new page must be loaded for the server to execute the code, which was the norm in the early days from the 90’s-2000’s and even the early 2010’s, but researchers have experimented and found that a better user experience can be had if the user is able to achieve their desired action(s) without having to reload the page. An example of this is when you go onto a retail website, e.g. Boots UK, using their store locator feature returns results with a map on the same page.

To achieve loading content on the same page without reloading requires the use of Ajax and client side languages. Therefore we need to make use of both client and server-side languages to deliver a completely functional and feature rich site or application.

For more details on the topic, you’ll be able to find multiple resources online. An article I found from CloudFlare: Client side vs. server side provides some additional information.