In this article you will learn:
- why you need a browser to display "a frontend" and what that means for hosting
- what you are actually deploying when you deploy a frontend
- what a CDN does, and whether you have to think about it at all
Previous post in the series ended with a stack of three layers. In this article we will focus on the top one - the UI (user interface).
First things first: a UI is just a page. Well, in most cases a group of pages with the same layout. Think of it as a graphical visualization of your app - like your face/body is a visual representation of you (mind inside).
Frontend is a fancy name for the files that - when displayed properly - show as a page in the browser. But how does it make sense for the browser to display those files as a graphic?
If frontend is not equal the UI, what is missing?
Browser - the magician behind the scenes
Most of us either use the system's built-in browser or an installed one and stop thinking about it. We know what features our browser has - but how does it work?
One of the key elements is DNS. Earlier in this series I described how DNS helps to translate a string (the name of your beloved website) into an IP address.
Animation: a browser address bar where mateusz-dev.pl is typed, a signal travels to a DNS server, and the server answers with the IP address 203.0.113.42.
The browser, on your behalf, connects to that IP address and requests files.
Those files are the frontend. The browser receives them and somehow magically displays them as a page (this process is called rendering). Well, that means the browser should be able to render "frontend" files from your local device (e.g. PC), right? Let's check it out.
index.html - the entry point of your frontend
Go to any folder on your computer and create a new file called index.html. Paste the following code:
<!DOCTYPE html>
<html lang="en">
<head>
<title>My First Static Page</title>
</head>
<body>
<h1>I am a static page!</h1>
</body>
</html>Save it and double click on it. Your browser should open and display "I am a static page!" in big letters. Congratulations! You just created your first frontend.
It looks ugly though!
Let's add a layer of instructions that would tell the browser how to display certain elements. Edit the HTML file so it looks like this:
<!DOCTYPE html>
<html lang="en">
<head>
<title>My First Static Page</title>
<style>
body {
background-color: #a1c1e1;
font-family: Arial, sans-serif;
font-size: 24px;
font-weight: bold;
text-align: center;
text-transform: uppercase;
padding-top: 50px;
}
h1 {
color: #333;
}
</style>
</head>
<body>
<h1>I am a static page!</h1>
</body>
</html>Open it again (or refresh the page in the browser). Now it looks nothing like before. With a few additional lines the browser completely changed the way it displays the text.
Styles are useful, but believe me - you don't want to put them in index.html (sometimes the number of style lines can be in the thousands). What to do then? Use a separate file called style.css!
style.css - page makeup in a separate file
In the same folder as index.html, create a new file called style.css with the content:
body {
background-color: #a1c1e1;
font-family: Arial, sans-serif;
font-size: 24px;
font-weight: bold;
text-align: center;
text-transform: uppercase;
padding-top: 50px;
}
h1 {
color: #333;
}Also remove the <style> tag from index.html. Reopen/refresh the page. Wait, we are back to square one! The browser does not know that it should use style.css file. We need to tell it about that.
Add the following line inside the <head> tag in index.html:
<link rel="stylesheet" href="style.css">Another refresh of the page and everything looks awesome again!
Browser superpowers
We just utilized the power of the browser to display the files.
The same process is used to display any internet page. It does not make much of a difference whether it is React, Vue, Angular, or any other frontend framework. Whatever framework you use, the core principle remains: the browser has a set of features that allow it to display files (using HTML, CSS, JS) in a way that looks like a page and those frameworks take advantage of that.
NOTE
React, Vue, and Angular differ a lot! The features, framework philosophy, keywords, syntax, and many other things are different. But the core principle of displaying files in the browser is the same.
Now, let's clear one more misconception.
Using JavaScript - does it break static hosting?
Well, I have not mentioned JavaScript yet, but it is the most important part of the frontend. It is the language that allows you to add interactivity to the page.
Do you want to display a notification? No problem - JS has got you covered. Want to keep some local data (in browser memory)? JS can do that too. Want to get data from some other page? JS can do that as well.
Let's see a simple example.
<!DOCTYPE html>
<html lang="en">
<head>
<title>My First Static Page</title>
<link rel="stylesheet" href="style.css">
</head>
<body>
<h1>I am a static page!</h1>
<button id="greet">Click me</button>
<script>
const button = document.querySelector('#greet');
button.addEventListener('click', () => {
alert('You clicked me!');
});
</script>
</body>
</html>If you paste this code into index.html and refresh the page, a new button will be visible. Click it. A small popup appeared! The browser has tools to run JS code, but that does not always mean the page stopped being static.
Static page - the breaking point
Let me give you an example of a non-static page first - it will be easier to draw the line from there.
Most of you have a bank account, right? Here. This is a non-static page! But what about it is non-static? For starters: login process 😅.
Your login and password that guard your account (and money) must be well protected in all stages of the communication between your PC/smartphone and the bank.
If a bank page were fully static, exactly the same page would be sent to all users. You can't bake in account security with just static files. The login process is not static by design - browser display static page with the login form. Those credentials are sent to the external system. In reponse, browser gets clear answer - either data was valid (and user redirected to the real app) or not (form show error message).
What about the account balance? It is not static either. It changes over time, and it is different for each user. The browser cannot know your balance without asking somewhere what the correct value is.
This shows that some features on the page require more than just the capabilities of the browser. This "something" is the so-called "backend" (a huge topic on its own).
NOTE
Quick summary: a static page is one that looks exactly the same for all users.
Example #1: A page for an event - it contains only well-known information: what food will be available, how much it costs, whether you need to bring your own toilet paper or it will be provided on site 😅
Example #2: You own a small business and want to showcase the services you provide. A static page might be the way to go! You won't be able to sell anything online, but people watching the results of your work (you have added pictures on the page) can contact you by phone/email (you have a contact page!) and request something.
Now is the time to answer the question this whole post has been circling: how do you actually host a frontend?
Hosting a frontend
Hosting is just a server that will return the index.html file and the files it references when someone's browser requests this page. Such a server must be:
- always up - otherwise your page will not be available on the internet
- blazing fast - user might get annoyed waiting for the page to load
- ready to serve multiple requests at a time
But there is more. Hosting nowadays is not just a server that allows you to send static files when a user requests them on your domain URL. More often than not, it is a suite of additional features such as:
- DDoS protection - block unwanted/malicious traffic
- back-ups - protect your data and be ready to rollback to older versions if needed
- TLS certificates (still sold as "SSL") - secure the communication between the user's browser and your server
- admin panel - intuitive configuration site, monitoring, etc.
- an easy way to install WordPress or alternatives
- support dedicated to your needs
Is hosting everything you need to host a page?
What would happen if your site were hosted by just a single server?
Imagine this: your frontend files sit on a machine somewhere. Say Frankfurt. A visitor in Sydney is 16,500 km away. How much time would it take to load our simple as possible page from the example above?
A signal travelling at the speed of light there and back needs roughly 2 × 55 ms = 110 ms — and that is the floor physics allows. These calculations make a few key assumptions: there is a direct line, no interference, no server/routing delay, etc.
The real value cannot be calculated exactly, but my best guess would be: ~1.1-2s.
This is semi-acceptable, but real pages have a bunch of references and those must be fetched as well for a fully operational website. Even with HTTP/2 (which can send many requests over one connection) can't fix this. E.g index.html can reference style.css and them reference google font. Each time request must cross a long distance and this can pile up closer to 3-6s!
How can we overcome this?
What is a CDN, and do you need one?
A CDN — a content delivery network — solves it by keeping copies of your files on machines around the world. A visitor's request goes to the nearest copy instead of to the only copy of your frontend:
A visitor in Sydney requests a page. The first request travels 16,500 km to the origin server in Frankfurt and back, taking around 300 milliseconds. A CDN then keeps a copy at a nearby edge in Melbourne, so the next request is answered from within Australia in around 20 milliseconds.
One machine in Frankfurt. One visitor in Sydney. 16,500 km between them.
That trip is the whole idea. The origin is the server where your files really live. The edge is a server with a copy. A cache hit means the nearby copy answered. A cache miss means it had to ask the origin first and then kept the file for a while. That while is the TTL (time to live) - after this time when next request for your page reaches edge server, it makes sure your webpage didn't change (if so, it requests a new version of it) and renews the page's freshness stamp.
On the other hand, when you update your site, the files living in the edge servers must be invalidated - or else they will serve an old version of the page, potentially with old prices, for example.
Does this sound like a big win? Absolutely! Most modern hosting platforms have this feature. It is so universal and useful that you should think twice before picking one without support for CDNs.
NOTE
A CDN is not hosting and cannot replace it. It only ever holds copies — delete the origin and the copies expire into nothing.
Two side effects worth knowing about. A CDN absorbs traffic spikes, so the day something of yours gets shared widely, the edge answers almost everything and your origin barely notices. And on search: Google does not rank you higher for using a CDN; it ranks you higher for being fast. The benefit is real but indirect.
When static hosting is not enough
It is crucial to understand static webpages to go a step further - to dynamic ones. Why?
Dynamic pages take advantage of the same principle: the browser does the magic to display a folder of HTML, CSS and JS files. Add fetching data, local data storage, conditional rendering (e.g. some pages are visible only to admins) and a few others - you have discovered the dynamic pages.
This sounds simple, right? Probably yes, but it is much more complicated than you would imagine...
