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
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.
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, 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:
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
Now things get complicated
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?