Servers may be the greatest invention since sliced bread. Maybe not the best, but it's up there at least. In a nutshell, servers are just computers or programs that provide data and resources to other devices, called clients, over a network. You are able to read this post because your client (your phone or computer's browser) requested data from this website's server, and the server responded. You communicate with servers many times a day, maybe without realising it. They hold up civilisation. And let you watch funny cat videos.

So, what can servers do? They can host websites, store data, handle email and more, but we'll keep our focus on web servers for now. There's a lot to servers, so we will keep it simple and only talk about how they serve websites and content for us to enjoy.

---

What are Web Browsers?

The client requests the data. The server serves the data. But how does the data actually look cool? Web Browsers, like Google Chrome, Firefox etc., are just clients that request a web page's data, transform it into the website, then display it to us. So if the client (the web browser) requests a web page, the server will retrieve the web page's data and send it back to the client. The data needs to be in a certain format, called HTML, for the browser to interpret it. There's going to be a lot of acronyms, so get ready.

HTML

HTML (Hypertext Markup Language) is the standard language of creating and structuring content on the web. It's those <h1> </h1> tag structures that you may have seen. These are the tags that define what the content is structured as. Using HTML, web browsers can know exactly how to lay out a website. Now we know how web browsers turn HTML into websites for us, we can go back a step to how our client finds the server, and how the server finds the data.

The request-response cycle

I'll start by explaining everything in detail to give you an idea of how it works. Communication between the client and the server starts through a request from the client. When you enter a URL (Uniform Resource Locator) into Google or any search engine, the browser must be able to find an address for where the website's server lives. The browser queries the DNS (Domain Name System) to translate the domain name, i.e. rileydev.io or google.com, into the server's home address. Every device connected to the internet has an address, called an IP address (Internet Protocol). Using this address, the browser can send an HTTP request to it, asking for specific files and data associated with that URL. HTTP, or the more secure version HTTPS is the standard, secure way of requesting data over the internet. It stands for Hypertext Transfer Protocol (no, that's not from Star Wars). If a protocol wasn't in place, then there'd be no way for computers to know what each other wants. Once the request has been received by the server, it gets analysed and then the data gets fetched from its storage. It can then send the data back to the browser with an HTTP response. Finally, the browser renders the content so that we can see it.

You may have some idea of how clients interact with servers now. I'll explain it again, but this time I'll use an analogy to try and properly drill it in.

1. You open up your browser -> You walk into a restaurant
2. You enter a URL to view a website -> You ask the waiter for steak and chips
3. The browser uses DNS to translate the URL into the server's IP address -> The waiter writes down "steak and chips"
4. The browser sends an HTTP request for the data to the server's IP address -> The waiter gives the order to the chef
5. The server finds the resources in its storage -> The chef cooks the steak and cuts the potatoes
6. The server sends the packaged data back to the browser via an HTTP response -> The waiter serves the mid-rare steak and chips to you

This cycle is just a method of communication between the client and the server. Though that last bit is important. Notice how you didn't ask for a mid-rare steak? In this restaurant, you don't get to choose, the chef is only allowed to cook the steak mid-rare. Just like how the data associated with the URL, i.e. the website's files, is structured in a certain way. Sometimes the data goes through processes in the server, and gets sent without the browser having to do much besides display it. But in many modern websites, the server sends data that needs to be sorted out on the client's end. This is known as Server-side rendering and Client-side rendering.

---

Client-side Rendering

Initially, the standard for rendering websites was Server-side. The server would send the data to the client all built, ready to be displayed. But over time, developers realised that you could just send a bundle of files, with all the scripts and HTML straight to the client to be built on their end. This led to the Client-side rendering approach. So what made this approach more effective? It allowed website developers to make SPAs (Single Page Applications) which is behind the responsive, app-like feel of modern websites - instant navigation, no full-page reloads, much richer interactivity. Websites began to feel more dynamic, while reducing load on the server. An early implementation of this was Gmail, if you've used it then you would have noticed how snappy and smooth it feels to flick between your emails.

Website developers either had the choice of building a website to be rendered Server-side, or Client-side. At the time of Client-side rendering being the standard, some glaring issues were noticed despite how engaging it made websites feel.

• Slower initial load times - The most prominent disadvantage. The browser has to download, parse and execute the JavaScript scripts in order to render the page. When the average user typically waits around 8 seconds for a site to load, time is of the essence.

• SEO issues - In order for search engines to find and display websites in rankings, they must crawl the website's pages to get all the content. The issue here is that crawlers struggle to crawl dynamically loaded pages, which CSR does.

There are other potential concerns with Client-side rendering, but for the sake of not trying to sound biased, I will only gloss over them. Security is a risk when sensitive logic like handling payments and authentication is exposed on the client. And if the client has JavaScript disabled, that same logic can't run, leaving the site blank or broken.

Because of these tradeoffs, developers decided that we needed a way to go back to the server, while keeping as much of the modern scripting and functionality as possible. Essentially, they asked, "Could we go back to how things were with server-sided rendering, while keeping as much of the good stuff from CSR as possible?". This is how the Server-side model made its comeback.

---

The Comeback of SSR - a hybrid model

I say comeback because, like we established earlier, SSR is what we started with. CSR was most definitely an improvement over SSR when it was developed, so developers found a way to carry over CSR on top of what made SSR so good. What that led to was a hybrid system, an SSR-first model with CSR where it was needed.

For both CSR and SSR, we have JavaScript frameworks that come with all the scripts and functionality built-in. An industry standard CSR-based framework is React. It was developed by the guys at Meta to be a simple way to build user interfaces, using code snippets called "components" to organise and reuse parts of the website. So React and other frameworks were responsible for the smooth SPA designs that we are familiar with. But to get the best of both worlds, newer frameworks like Next.js were developed to utilise the foundation of SSR, with the modern interactivity of CSR. Of course, there will be many other frameworks, and they all work for their own use case. There isn't a one-size-fits-all system when it comes to software. There are however key architecture design choices that work best for different types of websites. You just have to look at the bigger picture.

Marketing/blog websites

SSR is ideal for driving SEO and fast load times. But, these types of sites tend to be high traffic, and a fully SSR website would need a powerful server to keep it running. This is where it is best to shift some weight to CSR, to the client. It keeps costs down, with negligible noticeable differences in speed.

SaaS dashboard

CSR is almost essential for dynamically displaying the user's data. But the server still holds its weight when it comes to authentication, API key management and payment handling. Sensitive information must be handled very carefully, so either SSR works here or well implemented CSR.

For any project, it is best to look at the project as a whole, and decide what aspects need SSR and what needs CSR. A good rule to follow is to stick to SSR, but add CSR on top where it is needed. This keeps all the data and security concerns to a minimum, as they are handled on the server. But if you know what you are doing, then CSR can be used wherever to offload the strain on the server. Most importantly, you need to know what you are doing or you could end up with a vibe-coded mess, with exposed API keys, improper security protocols and poor password protection. Don't stake it all on one model - choose either where it is needed.

---

TL;DR

When you visit a website, your browser (the client) requests data from a server, which sends it back to be rendered as a page. Early websites were built entirely on the server before being sent over - but developers shifted towards building pages on the client's side instead, enabling the snappy, app-like feel of modern websites. Though this came with tradeoffs, and the industry largely moved towards a hybrid of both. The right approach depends on the project, but a good rule of thumb is to default to server-side and layer client-side on top where it's needed.

But what happens when the server can't keep up? That's for Part 2.