AI Essentials #2 - Server side and client side
Server side and client side are terms you will increasingly hear with the rise of agents on the internet. The choice matters more now because what an agent sees when it hits a website can be different than what a person with a browser sees, depending on whether the website is built server side or client side.
At its simplest, client side means the user's own computer, which they can control. Server side means a computer they don't control and can't touch.
What's important is that within a product, the choice is not completely one or the other. Some parts can be client side and other parts server side.
How websites get built
When a website is built client side, the server sends a near-empty version of a page and the JavaScript to build it. The user's browser runs that JavaScript to fill in the page after it loads. In that case, you might notice a slight lag before it appears. On the other hand, when a website is built server side, the server assembles the page and the browser renders it.
The impact of agents
When checking websites to crawl them or otherwise, many agents look for the raw HTML and leave. They don't want to wait for the full website to render in a browser because that takes longer. Some agents go further and build the page in their own browser with no window (a "headless" browser).
Why you would pick server side
Firstly, when a website is built server side, an agent looking for the raw HTML will find the full page, content and all. That means the website makes it into the "index" and, if someone, or something, only looks in the index, that's how they find you.
Secondly, building server side is vital when you want to retain information on a computer the user can't touch. Examples that are server side include anything that needs to be verified, such as a bank balance, or that the user shouldn't be able to change, such as whether something has been paid for.
Why you would pick client side
Missing out on being in an index is not always a bad thing. Firstly, some sites hold content you don't want people to find, like your Gmail inbox.
Secondly, applications that change constantly as you use them, such as parts of Notion, Jira, and Asana, are client side. That's because if those products were all server side, every little action would mean the server rebuilding and resending the whole page, a full reload each time. That constant reloading would cause lags and result in a poor user experience. Think of this reloading as running between cones that are a little further apart than they would be in a client side situation.
| Server side | Client side | |
|---|---|---|
| How it's built | The server builds the page and sends finished HTML. | The browser builds the page from JavaScript after it loads. |
| What an agent sees | The full content, already in the raw HTML. | An empty shell, often nothing. |
| Best for | Being found, and data the user shouldn't be able to change (a bank balance or whether something has been paid for). | Private content (Gmail), and apps that update constantly without lag (Notion, Jira). |
An analogy that might help
Finally, an analogy that helped me as I was thinking through this short article was playing golf.
For building a website, think of client side as the golfer filling in their own scorecard as they go, and server side as the golfer being handed their completed scorecard as they go.
Taking a data perspective, and sticking with the golf analogy, client side is where you're playing on your own or casually with some friends and so your score only matters to you. The golfer keeps their own scorecard.
If you're playing in a tournament or in a round that otherwise counts towards your handicap, then there's an official record that you shouldn't be able to touch. It will go against your profile at the golf club and other players can trust it. If you could change it, then the score would lose value because it's no longer trustworthy. Server side is the equivalent of the official record the golf club keeps.