Today, frontend development has more acronyms than a small airplane manual.
And even though it feels like a mess at first, the truth is that each concept exists to solve a very specific problem.
If you understand these fundamentals, you can decide what to use in each project without repeating formulas or falling for trends.
We’re going to explain them clearly and with just the right depth, as if I were telling it to a friend who genuinely wants to get good at this.
Single Page Application (SPA)
A SPA is an application where everything loads only once.
The HTML arrives almost empty, your JavaScript bundle is downloaded, and from that moment on the UI updates without reloading the page. You navigate between “screens” but never request another page from the server.
How it works in practice:
- React mounts your App inside a
<div id="root">. - Routing is handled by the browser, not the server.
- When you click a button or change the URL, React re-renders only what’s needed.
When to use it:
- Dashboards
- Admin panels
- Apps with lots of interaction
- Internal tools
Problems:
- SEO takes a hit (Google can index, but it’s not always perfect).
- The initial load time can be high if the JavaScript bundle is large.
Multi Page Application (MPA)
The classic web model: each URL corresponds to a different HTML file.
When you navigate, the browser requests a new page from the server.
Characteristics:
- You don’t rely on JavaScript to render.
- Ideal for simple sites where the content doesn’t change much.
Pros:
- Excellent SEO
- Total simplicity
- Very fast initial load
Cons:
- Slower navigation
- Less “app-like” experience
Client-Side Rendering (CSR)
This is what many SPAs use.
All rendering happens on the client side.
Flow:
- The server sends you an empty HTML file.
- The JS bundle is downloaded.
- Only then is the entire interface built.
The good:
- Very flexible.
- Ideal for “live” apps where everything changes frequently.
The bad:
- A “blank screen” until the JS loads.
- Poor SEO unless you add alternatives.
Server-Side Rendering (SSR)
The server generates the HTML before sending it.
When it reaches the browser, it's already fully rendered.
Flow:
- The user requests a URL.
- The server runs the code and builds the HTML.
- The browser receives it completely ready.
Advantages:
- Perfect SEO.
- Very fast Time To First Byte.
- Ideal for dynamic content.
Cons:
- Increases server load.
- If the page depends on many queries, rendering can be delayed.
Static Site Generation (SSG)
You generate static HTML at build time.
There’s no “server” computing anything when a user arrives.
Ideal for:
- Blogs
- Documentation
- Landing pages
- Sites with stable content
Advantages:
- Insane performance
- Cheap to host
- Secure (no backend to break)
Cons:
- Every change requires rebuilding the site.
- Not suited for content that changes by the minute.
Incremental Static Regeneration (ISR)
One of the great ideas of Next.js: static pages that regenerate automatically.
How it works:
- The page is generated once, like SSG.
- After a certain time (
revalidate), the page is regenerated again only when someone visits it. - You get almost real-time content while keeping static-site performance.
Perfect for:
- Blogs with posts that get updated
- E-commerce sites where prices change occasionally
- Semi-dynamic content
Streaming
Instead of waiting for the entire page to be ready, the server sends parts of the UI as soon as they’re available.
Benefits:
- The user sees content even while other parts are still loading.
- Better perceived performance.
- Allows expensive data fetching without blocking everything else.
React Server Components use streaming to send HTML while the server continues processing the rest.
Hydration
This is what happens when server-generated HTML becomes interactive on the client.
Types:
- Full hydration: hydrating the entire app.
- Partial hydration: hydrating only what’s necessary.
- Progressive hydration: hydrating components as they appear.
A key concept for hybrid environments like Next.js.
Edge Rendering
Rendering the page at the edge (CDN) instead of on a central server.
This reduces latency because the content is processed as close to the user as possible.
Great for:
- Global apps
- Region-personalized content
- Sites where every millisecond matters
In summary…
There’s no single approach that works for everything.
There are tools for different contexts:
- SPA → fluid experience
- MPA → simplicity + SEO
- CSR → pure interactivity
- SSR → dynamic content + SEO
- SSG → extreme speed
- ISR → the ideal hybrid
- Streaming → progressive loading
- Hydration → interactivity on already-rendered HTML
- Edge Rendering → global speed
When you understand these concepts, you can choose the right architecture for each project instead of relying on whatever stack happens to be “in fashion.”