An Illustrated Guide to Server-Side and Client-Side Code

The journey from web server to browser

Young Coder
Oct 18 · 6 min read
All pictures © the author

Once, many years ago, when the internet was first created, web pages were like ordinary documents. You wrote one, you saved it, and then you copied it to a web server. And there it stayed, forever the same, unless some day you decided to make changes and upload a new version.

This kind of web page is called a static page, because it doesn’t change (at least not on its own).

If someone wants to look at a static web page, they tell their browser where it is (using a web address). Then their browser asks the web server to share.

Let’s run code on the web server

For a while, life was very boring. But then, early web civilizations realized they could make something much more powerful if they stopped writing web pages and instead built robots that could write web pages. Except they didn’t actually use robots. Instead, they built programs — programs that could generate web pages dynamically.

These programs are called server-side web applications, because all the code runs on a web server (the super-powered computer you never see, which is hidden in a rack in some giant data center at the ends of the earth).

Here’s how it works. When you ask for a page, the web server runs some code. This code builds the web page. For example, you ask Google for pictures of cats, and it custom-makes you a page. With cats. Lots of cats.

There are a whole bunch of server-side programming technologies, from barebones and straightforward ones like PHP (the old granny of the internet world) to whole platforms like ASP.NET and Ruby on Rails. They often look different and have different programming models. But at the end of the day, they all start with a web request and they all end by building an HTML page.

Are server-side applications awesome?

Server-side applications are pretty awesome, because web servers are powerful and they have access to a whole lot of information. For example, think of Amazon. You can’t just peek in Amazon’s databases. But you can go to its site and ask it to find you all the products with cats. If you do, Amazon runs a server-side application, gets the information you want, and builds you a nice page.

But even though server-side applications are awesome, they aren’t awesome for every type of page.

For one thing, pure server-side applications aren’t good for building highly interactive applications, like games, mapping tools, drawing programs, whatever. That’s because every time you want your code to run, you need to call up the web server again and get a new, updated page. Imagine making a game this way.

There are ways to fix this. But they all need the help of client-side code.

Let’s run code in the web browser

Client-side code is code that runs in your browser. It always uses JavaScript, because that’s the only language that every browser understands (for now).

When people first learn about client-side code, they sometimes ask “Where does it come from?” It comes from the web server, of course, just like everything else. The important thing is it doesn’t run there — instead, it’s sent to your computer along with the page (and the pictures, style sheets, fonts, and everything else a truly bodacious page needs).

The problem with a client-side code is… what can it do? It’s like a castaway marooned on a desert island. Your computer doesn’t have Amazon’s product catalog. Your computer doesn’t have Google’s search database. And when code runs in a web browser, it’s not allowed to do the sorts of things that other applications can do, like read the files on your computer or access your computer’s hardware.

In the old days, people used JavaScript to do little gimmicks like making buttons glow or collapse sections of a page — things that are now handled better by styles. Or they made really simple mini applications, like calculators and quiz games. But we’re past that stuff. Today, web developers make better applications that run code in both places.

Let’s run code both places

Even though there are exactly 1.6 zillion different web development frameworks, they all have the same underpinning. If you want to run code on the web server and the client (the browser), you must use a magic object called XMLHttpRequest.

XMLHttpRequest is a special JavaScript ingredient with a superpower. It runs in the background and makes a request to a web server. Using XMLHttpRequest, you can make a client-side application that asks the web server to do something (like sending over some information about cats). Best of all, this all happens quietly and discreetly. There’s no need to lock up the browser or refresh the whole page. In fact, the person using the application won’t even realize that this communication is happening.

When you use XMLHttpRequest, things start to get more involved. Here’s a quick overview of how it might play out in an application:

One thing you might not realize from looking at this picture is that the JavaScript application keeps running in the web browser while it’s waiting for a response from XMLHttpRequest. A complex application might even make several requests at once before it gets any answers back.

One of the first and most famous applications to use XMLHttpRequest was Google Maps. It has all the fancy interactives features of JavaScript (so you can drag around, click on things, and so on) and it all also fetches the latest map data from Google’s web servers as you need it.

Now things get complicated

If you’re a programmer making a modern web application, there are a lot of parts to build. You need to write the JavaScript that runs in the browser. You also need to write the code that runs on the web server. (Incidentally, the part that runs on the web server used to be called a web service, but now people usually call it a web API.)

Here’s where things get complicated. Modern web applications need to use a stack of different technologies. There are JavaScript libraries in the browser (things like Angular, React, and Vue), and even more programming frameworks that can go on the web server. In fact, this stack is of technologies is so complicated that the people who understand both halves of the equation are given the legendary title Full Stack Developer and treated with mythological reverence.

Just recently (in the last few years), developers have been exploring ways to unify their stack. One approach is to use the same language on both sides (which, right now, means running JavaScript on the web server through a technology called Node). Another idea is to use a framework that lets you have the same programming model in both places (a technology called isomorphic applications), which is still filled with plenty of quirks and complications. But the future is marching forward, and there are better things on horizon — things with even more features and no less cats.

Have a suggestion for a future programming topic you’d like to see illustrated? Drop a comment below! And if you liked this article and want a once-a-month newsletter with links to our best new content, why not subscribe to the Young Coder newsletter?

Young Coder

Hack. Code. Think. Stories about science, tech, and programming.

Young Coder

Written by

Guest posts for the Young Coder publication.

Young Coder

Hack. Code. Think. Stories about science, tech, and programming.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade