Server-side vs Client-side Development

Server-side, client-side? Front-end, back-end? What's the difference and why does it matter? While the differences can be easily defined (we'll do that in a minute), there are several important factors that affect how we decide which one to use for a certain task. For the scope of this post we will only be talking about web development as server/client relationships exist in many other areas of IT as well.

Client-side / Front-end

In our context (web development) the client is the web browser (Chrome, Firefox, Safari, etc.) Therefore, when we say client-side we mean anything that is happening within the web browser. This is considered the front-end because it is facing the user. So, front-end entails the user interface (UI), design, and several other, generally smaller, components that either run in or are displayed by the user's browser. Anything that is client-side must by definition reside on the client and is therefore accessible to the user.

Note: This is a sufficient definition of client-side but the line between front-end and back-end isn't quite this clear cut when dealing with large complex solutions such as web apps.

Server-side / Back-end

This refers to the webserver(s) in our context. This may be a single webserver or a vast and complicated architecture of servers. Either way, it is out of the users control. In a certain sense, this entails anything that is not client-side including caches and third-party services. It is behind the front-end from the position of the user so it is called back-end.

How they interact

Examples usually help so we'll think about this as it pertains to this blog post. You saw a link to this webpage somewhere and clicked it. That initiated a request from your client to our server for this webpage. Your browser only sends certain information about itself by default so while we may know if you are using an iPhone vs a desktop, there is no way to initially know things such as if you have an external monitor or not or what timezone you are in. Our server (the back-end) could respond by trying to figure out certain things like that and then, once it has all necessary information send out a webpage customized for that device. In fact, that is how many webpages used to function. However, nowadays that is generally slow and inefficient. Instead, our server simply responds with everything necessary for the user's browser (the front-end) to display the webpage appropriately given the different variables. Let's take a look at what some of those are.

Timezones

Users generally want to see dates and times in their current timezone and in the format that they are most accustomed to. Therefore, it is generally most efficient for the back-end to send all dates in a standard time format such as UTC and then let the front-end convert that into the local time and format.

Images

On desktops and laptops it is important to display large resolution images that look good when displayed on a monitor. However, on mobile devices this is less important and reducing the amount of data used and the time to load is more important. The back-end can send over instructions for multiple different images and tell the front-end which ones to use under which circumstances (e.g. mobile, tablet and desktop).

Forms

There are many instances where users fill out forms of different types. We've all been to a site filled out a form and after submitting it, waited a few seconds to be taken to a page that says that we missed something or filled something in wrong. This is because the website in question isn't checking the fields on the client-side, it must be sent to the server to verify if it is valid or not. It is considered best practice to perform most of this validation on the client-side so that the user can instantly know whether or not they have filled it in correctly. This also saves the server from having to process invalid submissions.

Additional Features

The advent and growth of client-side scripting has led to many new features that were not possible before. You may have noticed that in recent years websites now ask for you to allow access to your location, to display notifications and many other things. These are all powered by client-side scripts and these features aren't available to server-side only applications.

Performance

Generally, it is better to offload as much processing as possible to the client. This can drastically reduce the number and types of servers required and therefore the cost to run and maintain them. This also gives the users a better experience as pages load faster and they use less data.

How we decide which one to use

We handle this on a case-by-case basis. Generally, there will always be a mixture of both server-side and client-side programming. We balance the impacts on the user experience, maintainability, cost and development time to make these decisions. Here are a few specifics that we consider:

Server-side

Pros

• The user cannot access server-side code so it can be kept proprietary
• Servers are generally very powerful and can do much more processing that clients
• Server-side code is essential for authentication and security related tasks as the user could manipulate anything on the client-side
• It has access to all resources of the server or application such as files, databases etc.

Cons

• You have to pay for all processing that happens on the server(s)
• Can be poor for user experience (UX) as it required data to be sent back and forth

Client-side

Pros

• Can give nearly instantaneous feedback to the user
• Free (You don't pay for the users' processing power)
• Can give you access to additional features that aren't available to the server
• By leveraging client-side features, it can reduce server load

Cons

• Users can see any code that is running in their browser
• Can't do everything, some things must be sent to the server