The Junior Developers Complete Guide to SSR, SSG and SPA
Every dev tools company and -team seems to assume that Junior Devs are familiar with these terms.
When I started to code, I saw them everywhere: Nuxt is an SSR framework, you can use Gatsby for SSG, and you can enable SPA mode if you set this or that flag in your next.config.js.
What the hell?
As a first step, here's a glossary – though it won't help you to understand the details:
- CSR = Client-Side Rendering
- SPA = Single Page Application
- SSR = Server-Side Rendering
- SSG = Static Site Generation
Next, let's shed some light into the dark.
Static Web Servers
Initially, a website was an HTML file you requested from a server.
Your browser would ask the server, "Hey, can you hand me that /about page?" and the server would respond with an about.html file. Your browser knew how to parse said file and rendered a beautiful website such as this one.
We call such a server a static web server. A developer wrote HTML and CSS (and maybe a bit of JS) by hand, saved it as a file, placed it into a folder, and the server delivered it upon request. There was no user-specific content, only general, static (unchanging) content accessible to everybody.
app.get('/about', async (_, res) => { const file = fs.readFileSync('./about.html').toString(); res.set('Content-Type', 'text/html'); res.status(200).send(file); })
Interactive Web Apps & Request-Specific Content
Static websites are, however, boring.
It's much more fun for a user if she can interact with the website. So developers made it possible: With a touch of JS, she could click on buttons, expand navigation bars, or filter her search results. The web became interactive.
This also meant that the /search-results.html page would contain different elements depending on what the user sent as search parameters.
So, the user would type into the search bar, hit Enter, and send a request with his search parameters to the server. Next, the server would grab the search results from a database, convert them into valid HTML, and create a complete /search-results.html file. The user received the resulting file as a response.
(To simplify creating request-specific HTML, developers invented HTML templating languages, such as Handlebars.)
app.get('/search-results', async (req, res) => { const searchParams = req.query.q; const results = await search(searchParams); let htmlList = '<ul>'; for (const result of results) { htmlList += `<li>${result.title}</li>`; } htmlList += '</ul>'; const template = fs.readFileSync('./search-results.html').toString(); const fullPage = embedIntoTemplate(htmlList, template); res.set('Content-Type', 'text/html'); res.status(200).send(fullPage); });
A short detour about "rendering"
For the longest time, I found the term rendering highly confusing.
In its original meaning, rendering describes the computer creating a human-processable image. In video games, for example, rendering refers to the process of creating, say, 60 images per second, which the user could consume as an engaging 3D-experience. I wondered, already having heard about Server Side Rendering, how that could work — how could the server render images for the user to see?
But it turned out, and I realized this a bit too late, that "rendering" in the context of Server- or Client-Side Rendering means a different thing.
In the context of the browser, "rendering" keeps its original meaning. The browser does render an image for the user to see (the website). To do so, it needs a blueprint of what the final result should look like. This blueprint comes in the form of HTML and CSS files. The browser will interpret those files and derive from it a model representation, the Document Object Model (DOM), which it can then render and manipulate.
Let's map this to buildings and architecture so we can understand it a bit better: There's a blueprint of a house (HTML & CSS), the architect turns it into a small-scale physical model on his desk (the DOM) so that he can manipulate it, and when everybody agrees on the result, construction workers look at the model and "render" it into an actual building (the image the user sees).
When we talk about "rendering" in the context of the Server, however, we talk about creating, as opposed to parsing, HTML and CSS files. This is done first so the browser can receive the files to interpret.
Moving on to Client-Side Rendering, when we talk about "rendering", we mean manipulating the DOM (the model that the browser creates by interpreting the HTML & CSS files). The browser then converts the DOM into a human-visible image.
Client-Side Rendering & Single Page Applications (SPAs)
With the rise of platforms like Facebook, developers needed more and faster interactivity.
Processing a button-click in an interactive web app took time — the HTML file had to be created, it had to be sent over the network, and the user's browser had to render it.
All that hassle while the browser could already manipulate the website without requesting anything from the server. It just needed the proper instructions — in the form of JavaScript.
So that's where devs placed their chips.
Large JavaScript files were written and sent to the users. If the user clicked on a button, the browser would insert an HTML component; if the user clicked a "show more" button below a post, the text would be expanded — without fetching anything.
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>Document</title> </head> <body> <div id="root"></div> <script> document.addEventListener('DOMContentLoaded', () => { const root = document.getElementById('root'); root.innerHTML = ` <h1>Home</h1> <button>About</button> `; const btn = document.querySelector('button'); btn.addEventListener('click', () => { root.innerHTML = ` <h1>About</h1> `; }); }); </script> </body> </html>
Though the code snippet suggests the opposite, developers didn't write vanilla JavaScript.
Ginormous web apps like Facebook had so much interactivity and duplicate components (such as the infamous Like-button) that writing plain JS became cumbersome. Developers needed tools that made it simpler to deal with all the rendering, so around 2010, frameworks like Ember.js, Backbone.js, and Angular.js were born.
Of them, Angular.js was the one that brought Single Page Applications (SPAs) into the mainstream.
An SPA is the same as Client-Side Rendering, but it is taken a step further. The conventional page navigation, where a click on a link would fetch and render another HTML document, was taken over by JavaScript. A click on a link would now fire a JS function that replaced the page's contents with other, already preloaded content.
For this to work properly, devs needed to bypass existing browser mechanisms.
For example, if you click on a
Devs invented all kinds of hacks to bypass this and other mechanisms, but discussing those hacks is outside the scope of this post.
Server-Side Rendering
So what were the issues with that approach?
SEO and Performance.
First, if you look closely at the above HTML file, you'll barely see any content in the
tags (except for the script). The content was stored in JS and only rendered once the browser executed the
Hot AI Tools

Undress AI Tool
Undress images for free

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Clothoff.io
AI clothes remover

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

The scope of JavaScript determines the accessibility scope of variables, which are divided into global, function and block-level scope; the context determines the direction of this and depends on the function call method. 1. Scopes include global scope (accessible anywhere), function scope (only valid within the function), and block-level scope (let and const are valid within {}). 2. The execution context contains the variable object, scope chain and the values of this. This points to global or undefined in the ordinary function, the method call points to the call object, the constructor points to the new object, and can also be explicitly specified by call/apply/bind. 3. Closure refers to functions accessing and remembering external scope variables. They are often used for encapsulation and cache, but may cause

CompositionAPI in Vue3 is more suitable for complex logic and type derivation, and OptionsAPI is suitable for simple scenarios and beginners; 1. OptionsAPI organizes code according to options such as data and methods, and has clear structure but complex components are fragmented; 2. CompositionAPI uses setup to concentrate related logic, which is conducive to maintenance and reuse; 3. CompositionAPI realizes conflict-free and parameterizable logical reuse through composable functions, which is better than mixin; 4. CompositionAPI has better support for TypeScript and more accurate type derivation; 5. There is no significant difference in the performance and packaging volume of the two; 6.

There are two core methods to get the selected radio button value. 1. Use querySelector to directly obtain the selected item, and use the input[name="your-radio-name"]:checked selector to obtain the selected element and read its value attribute. It is suitable for modern browsers and has concise code; 2. Use document.getElementsByName to traverse and find the first checked radio through loop NodeList and get its value, which is suitable for scenarios that are compatible with old browsers or require manual control of the process; in addition, you need to pay attention to the spelling of the name attribute, handling unselected situations, and dynamic loading of content

There is an essential difference between JavaScript's WebWorkers and JavaThreads in concurrent processing. 1. JavaScript adopts a single-thread model. WebWorkers is an independent thread provided by the browser. It is suitable for performing time-consuming tasks that do not block the UI, but cannot operate the DOM; 2. Java supports real multithreading from the language level, created through the Thread class, suitable for complex concurrent logic and server-side processing; 3. WebWorkers use postMessage() to communicate with the main thread, which is highly secure and isolated; Java threads can share memory, so synchronization issues need to be paid attention to; 4. WebWorkers are more suitable for front-end parallel computing, such as image processing, and

Type casting is the behavior of automatically converting one type of value to another type in JavaScript. Common scenarios include: 1. When using operators, if one side is a string, the other side will also be converted to a string, such as '5' 5. The result is "55"; 2. In the Boolean context, non-Boolean values will be implicitly converted to Boolean types, such as empty strings, 0, null, undefined, etc., which are considered false; 3. Null participates in numerical operations and will be converted to 0, and undefined will be converted to NaN; 4. The problems caused by implicit conversion can be avoided through explicit conversion functions such as Number(), String(), and Boolean(). Mastering these rules helps

Format dates in JavaScript can be implemented through native methods or third-party libraries. 1. Use native Date object stitching: Get the date part through getFullYear, getMonth, getDate and other methods, and manually splice it into YYYY-MM-DD and other formats, which is suitable for lightweight needs and does not rely on third-party libraries; 2. Use toLocaleDateString method: You can output such as MM/DD/YYYY format according to local habits, support multilingual, but the format may be inconsistent due to different environments; 3. Use third-party libraries such as day.js or date-fns: Provides concise syntax and rich functions, suitable for frequent operations or when extensibility is required, such as dayjs()

Initialize the project and create package.json; 2. Create an entry script index.js with shebang; 3. Register commands through bin fields in package.json; 4. Use yargs and other libraries to parse command line parameters; 5. Use npmlink local test; 6. Add help, version and options to enhance the experience; 7. Optionally publish through npmpublish; 8. Optionally achieve automatic completion with yargs; finally create practical CLI tools through reasonable structure and user experience design, complete automation tasks or distribute widgets, and end with complete sentences.

Use document.createElement() to create new elements; 2. Customize elements through textContent, classList, setAttribute and other methods; 3. Use appendChild() or more flexible append() methods to add elements to the DOM; 4. Optionally use insertBefore(), before() and other methods to control the insertion position; the complete process is to create → customize → add, and you can dynamically update the page content.
