Breaking down the frontend ecosystem

Reading up on how frontend really works

There’s so many frameworks, paradigms these days that keeping track of how frontend works is quite tricky. It’s very easy to get started on this frameworks. Boilerplates makes this especially easy. Running: npm create vite@latest my-vue-app -- --template react creates an application in a flash! This makes getting started on a website or web application extremely easy. What this doesn’t do is teach you how things work under the hood. The ease of usage has made all the tech underneath seem like magic. It’s good in a sense that it makes you work quicker (which is the main purpose of all tools) but bad in the sense that it abstracts all the details out. This makes choosing tools and paradigms you use much less obvious.

As someone who did not go through computer science this knowledge was never with me but I’m determined to get to the bottom of it.

How does a website work?

What is a browser? A browser is application that renders a websites. At its core, it works by fetching from a webserver via HTTP request, a html file. It then uses this to paint a page. This is what happens when you access an URL. A URL points to a particular server via DNS. Remember when you originally purchase a domain from GoDaddy? GoDaddy gives you access to a domain and ability to change the DNS records. Using this and modifying the A record, you can redirect a url to a webserver ip.

Simplified

URL -> DNS -> Webserver

Key points:

• Browser fetches files and renders them.
• All you need is to send html files to client browsers. JS and Css are additional sauce.

Frameworks

Now a single plain webpage is quite boring. Most websites wants to have different pages. This brought about routing

As websites get increasingly more and more complex there was a need to make developing them easier. This is where frameworks come in. Frameworks are created to make developers life easier. Writing pure js to listen for events, change elements via the dom is doable but a huge huge pain. Frameworks use js extensively to modify the html document when there are new data.

Now when you write .jsx or .svelte files, these files cannot be read by the browser. Recall that the browser only understands html, css and js. This means that the files has to be converted into these files. This is where a transplier (transformation compiler) come in. It basically converts all your .jsx files into readable js. Notice when you generate a build, all the build files are js/css/html files!

Performance

We all want to serve our users better and performance is a huge deal. One of the laws on ux is to ensure less than 400 ms. This leads to focuses on different problems and clever people solving them in different ways.

How does bundling work? Reducing bundle size.

To preface bundling is the process of combining all required files into one distributable. To make it the most performant, you generally

Working out where everything is used is difficult.

This runs the transplier and minifiers. Popular bunndlers are rollup and webpack.

With frameworks comes with a lot of js. This means the files served get large. For users with limited bandwidth this can cause a very slow website. Minifiers. All text files are made up of bytes. The less characters, the less bytes. Minifiers do this by removing all whitespaces, comments, shortens variable names and shortens functions. It’s kind of like performance linter!

If you check your dist files, they are almost unreadable through this process but is actually still your code.

Rendering strategies. Performance SSG, CSR and SSR.

Another main thing to determine is the exact way to produce the html. Because js can amend our html via the dom it’s possible to do everything client side. Heres the popular 3 strategies.

SSG - Static site generation. All HTML files are generated during the build step. Good for pages that are the same for everyone. CSR - Client side rendering. The initial Html is an empty shell. All elements are added via js. Additional requests made client-side for data. SSR - Server side rendering. Server provides an rendered html file (with user data etc). Elements are then hydrated (process to attach js back to the rendered html) to provide dynamic content. Transitional Apps - Coined by Rich Harris this is essentially combining all the strategies and use one which fits the usecase.

This was particularly hard for me to understand. I think the point I had to get over is that the term rendering here means the process to make the webpage show the correct initial html. Nothing more. All subsequent handling and dynamic content is still done via js.

Routing:

• Server-side routing. The default behaviour where each route reloads the whole html.
• Client-side routing. Redirection (link, forward and back) is intercepted and handled on client side. Faster without full reload.

Frontend Infrastructure

https://vercel.com/docs/projects/domains https://en.wikipedia.org/wiki/Root_name_server

DNS - Domain Name System Rich Harris on Transitional apps