Client-side vs. Server-side: what’s the difference?

We know you’re busy coding something cool. You’re short on time to study up on the
difference between client-side development and server-side development. That’s where we
come in. We sat down with our Head of Technology to give you a cheat sheet on everything
you need to know about client-side vs. server-side, so you can get down to building
something awesome.
How do they fit together?
It’s hard to figure out the differences between the two without first talking about how they
can fit together. So let’s imagine building a house. It could be your childhood home, your
dream home, that weird house down the street (yeah, you know the one).
When you’re building a house, client-side development is the paint, the trim, the doors, the
colour — the usability, the attention to detail. It’s all about the user experience.
Server-side development is the structural part of building a house. It’s the pipes, the electrical,
the wood and the concrete that help your house stand up and stay secure.
What is client-side?
In the client-server model, where users connect their computers to servers in order to view a
dynamic website, the client-side is everything that is displayed on the user’s device.
Everything from the images and text displayed to the UI of a web browser make up client-
side. This is often referred to as the front-end of web development.
Client-side code often uses HTML, CSS, and JavaScript. Static JSON files are a common
way to access files dynamically, and AJAX is a way to load and change content on a client-
side website dynamically. Cookies can be used to store data.
This kind of development is highly reliant on the browser to actually work. Without the
browser, your code won’t do sh*t. In short — no browser, no client-side application. In
client-side development, you technically don’t need a server to build a website. In fact, you
could create a website that’s fully graphical and interactive (even making a game!), loading
and storing data and running it on your computer within your browser, and never even have
to touch a server, database, or processing environment. Crazy, right? The logic, assets, and
brains can all be self-contained within the client-side files (HTML, JavaScript, CSS, JSON,
images, etc.) you created.
What’s cool about client-side development?
There’s lots to love about client-side development. Here are some of our favourite things
about it:
 It’s easy to learn
 It gives you the chance to show off your creative side
 You can create really cool sh*t that’s dynamic and fun to use
 99% of client-side libraries and development tools are free to use, with only a few
resources that have a cost attached
What sucks about client-side development?
Client-side is a lot of fun, but it has its sore points:
 Because it relies on browsers, browsers cause load problems since they behave in
different ways (cross-browser issues)
 You can do cool stuff like load and save data, but it’s limited by both the languages
you use and the browsers themselves, so you may hit a wall if you want a certain
functionality (ie. pulling in live data from somewhere, sending emails, doing
payments, managing data)
 Challenges with mobile-first development, since what you expect to do on a desktop
doesn’t always work on mobile
 Relies heavily on third-party tools and resources, which can be poorly maintained,
documented, and even coded
 Limited by languages — only uses HTML, CSS, and JavaScript, or languages like
VBScript which are only compatible with Windows in Microsoft Edge and Internet
Explorer
Now that we know about client-side, let’s take a look at server-side.
What is server-side?
Server-side refers to the processing that executes whatever the user is trying to do and makes
the exchange of information possible. This is where the data and source code are stored, and
so it is often referred to as the back-end. The server-side processes user requests on a web
page and sends information back to the client. It is used for anything that requires dynamic
data, such as login information, running payments, pulling live data, sending emails, and
other complex functions.
While server-side executes results that the user can see on their end, server-side is invisible to
the user. Popular server-side languages used in the back end of development include Java,
PHP, .NET, Python, and Ruby on Rails.
One important thing to know about server-side code is that it usually sits on a server, and the
server is responsible for serving the client-side code to the end user. In most cases, if a
website is going to be publicly accessible, even one that’s purely client-side, it has to sit on a
server somewhere. Technically, server-side code doesn’t have to interact with client-side code
at all. You might have server-side code that processes and analyzes data and does lots of cool
and complex things behind the scenes, like dealing with databases, other servers, files, AI,
third-parties, and machine learning.
What’s cool about server-side development?
There’s lots to love about server-side development. Here’s what we rave about:
 Basically, without server-side code, the Internet and all the things we do online today,
wouldn’t be possible. Pretty cool, huh?
 It’s complicated, dynamic, and yes, we’re also gonna say that it’s beautiful and
artistic. Yeah. We went there.
What sucks about server-side development?
Okay, yeah, server-side can be tough. Here’s why:
 There are a million different languages out there that can do server-side code, so it’s
hard to figure out where to start and what to learn
 It’s complex and can involve infrastructure, devops, software applications — and all
of that makes the learning process difficult at times
 There are SO MANY third-party components, libraries, platforms, software, apps, you
name it — so there are issues with maintenance, documentation, and support
especially in the open-source world
 Issues with compatibility — not only between languages (ie. what you do in Java
cannot be applied to PHP), but within languages too (ie. version changes and
depreciation)
 Lots of open-source components are free, but plenty also have a cost associated with
them
 Server-side needs a server to work (we know, you’re thinking duh). But unlike client-
side, where all you need is a browser and a simple text file, server-side is a lot more
complicated to set up because it needs to be compiled and executed properly. There’s
a gray area with serverless server-side development (ie. NodeJS), but you still need a
server even with a node.
Client-side vs. server-side comparison
We just gave you a lot of information. Here’s a chart to help you understand the main
differences.

Where do I fit in?

So, what’s the main difference between client-side and server-side development? The two
sides of the client-server model are separated by the kind of code they use and their purpose,
but they work together. While client-side is typically referred to as the front-end and server-
side as the back-end, this doesn’t mean that they don’t interact with each other, or that you
can’t work with both. Even if you’re not a full-stack developer (who manages both sides of
the relationship), there are lots of places where the two ends work together to make a
cohesive process for the user.
So, if you’re just getting into web development, how do you know which side of the client-
server model you’ll enjoy working with more?
Besides deciding based on which coding languages you’re most comfortable with, ask
yourself what drives you. Do you want to build the structure of the house or design what it’s
like to live in it?
If you’re interested in greater flexibility for your code, server-side is for you. Server-side
offers more control, particularly over security, and that makes it a great challenge for anyone
looking to test their strengths by building something long-lasting.
On the other hand, if you’re passionate about the user experience and building pages that are
dynamic and beautiful, client-side may be your jam. You’ll get to indulge your creative side
by building a seamless UI.
Whichever side you’re working on, you’ll be sure to build something great.