Recommended resources
The freely available resources this lesson will direct you to.
Hello! Welcome to the first lesson in our course on transforming React SPAs to modern SSR/SSG applications with Tanstack.
Given your extensive experience leading front-end development, you're deeply familiar with the architecture and behavior of Single-Page Applications (SPAs). This course is designed to build upon that expertise, equipping you with the patterns and tools to leverage server-side rendering for enhanced performance and user experience.
Today, we'll start with the foundational "why" before we get to the "how." Our goal is to analyze the architectural trade-offs between Client-Side Rendering (CSR), Server-Side Rendering (SSR), and Static Site Generation (SSG). Understanding these core rendering strategies is the critical first step in making informed architectural decisions for any large-scale web application, and it will provide the essential context for our migration project.
Let's begin by exploring the modern rendering landscape.
1. The Spectrum of Web Rendering
At its core, "rendering" is the process of turning your application's code and data into the interactive HTML that users see in their browsers. The fundamental difference between the patterns we'll discuss today lies in where and when this process happens.
To get a quick, high-level overview of the main rendering patterns and their trade-offs, please watch the following segments from the video "10 Rendering Patterns for Web Apps."
10 Rendering Patterns for Web Apps
This video provides a concise tour of modern web rendering techniques. It's a great way to quickly map out the territory we'll be exploring.
Please watch the following sections: Single-Page Applications (SPA) Server-Side Rendering (SSR) Static Site Generation (SSG) As you watch, focus on the primary advantages and disadvantages mentioned for each approach.
As the video highlights, the choice of rendering pattern is a game of trade-offs involving performance, user experience (UX), developer experience (DX), and infrastructure costs. Now, let's dissect each of the three main patterns in more detail.
2. A Deeper Dive into Rendering Patterns
To better understand the mechanics of each pattern, it's helpful to think about where the main workload occurs: at build time, on the server (at request time), or on the client (in the browser).
The following video provides an excellent mental model for this. We'll use it to break down each pattern.
This video from Web Dev Simplified does a fantastic job of illustrating how the workload is distributed across the build, server, and client phases for each rendering pattern.
First, watch the section 'Understanding the web request process'. This establishes the framework we'll use to compare the rendering models.
Now, let's apply that framework to CSR, SSR, and SSG.
Client-Side Rendering (CSR)
This is the paradigm of the classic SPA, which you've mastered over the years. The server's role is minimal: it just serves a nearly empty HTML shell and a large JavaScript bundle.
Let's review the CSR model you're familiar with, but through the lens of this workload analysis.
Watch the section on Client-Side Rendering (CSR). Notice how it emphasizes that nearly all work is offloaded to the client.
Key Trade-offs for CSR:
- Pros:
- Rich Interactivity: After the initial load, navigation and UI updates are fast and fluid, creating an "app-like" experience.
- Reduced Server Load: The server is simple and stateless, primarily acting as a static file host and API provider.
- Cons:
- Slow Initial Load: The user sees a blank page until the JavaScript bundle is downloaded, parsed, and executed. This negatively impacts metrics like First Contentful Paint (FCP).
- SEO Challenges: Search engine crawlers may see an empty page, making it difficult to index content without specialized execution of JavaScript.
- Performance depends on Client Device: Slower devices or networks result in a significantly degraded user experience.
Server-Side Rendering (SSR)
SSR aims to solve the main problems of CSR (slow initial load and poor SEO) by generating the full HTML for a page on the server in response to a user's request.
Now let's look at how SSR shifts the workload.
Watch the section on Server-Side Rendering (SSR). Pay close attention to the concept of 'hydration,' which we will cover in detail in the next lesson.
As shown in the diagram above (middle path), the server fetches data and renders the complete HTML page, sending it to the browser. The browser can display it immediately. Then, client-side JavaScript loads and "hydrates" the static HTML, attaching event listeners and making the page interactive.
Key Trade-offs for SSR:
- Pros:
- Excellent SEO: Search engines receive fully-rendered HTML, ensuring reliable indexing.
- Fast First Contentful Paint (FCP): Users see meaningful content almost immediately, improving perceived performance.
- Cons:
- Higher Server Load & Cost: Every request requires the server to fetch data and render HTML, which is computationally more expensive than serving static files.
- Slower Time to First Byte (TTFB): The server needs time to generate the page before sending the first byte of the response.
- Longer Time to Interactive (TTI): While the page is visible quickly, it's not interactive until the JavaScript has loaded and hydration is complete.
Static Site Generation (SSG)
SSG takes the SSR idea one step further: instead of generating the HTML on every request, it generates it once at build time.
Finally, let's examine SSG, where the rendering work is front-loaded into the build process.
About seven minutes in, watch the section on Static Site Generation (SSG). Note how this model nearly eliminates both server and client workload at request time.
The result is a collection of pre-built HTML files that can be served instantly from a Content Delivery Network (CDN). This is illustrated in the diagram's right-most path.
Key Trade-offs for SSG:
- Pros:
- Fastest Possible Performance: Serving pre-built HTML from a CDN is incredibly fast, leading to excellent TTFB and FCP.
- High Security & Low Server Cost: No server-side computation at request time means a smaller attack surface and minimal infrastructure needs.
- Excellent SEO: Like SSR, it provides fully-rendered HTML to crawlers.
- Cons:
- Not for Dynamic Data: Content is "frozen" at build time. Any change requires a full site rebuild and redeployment.
- Long Build Times: For large sites with thousands of pages, the build process can become prohibitively slow.
3. Analyzing Trade-offs for Large-Scale Applications
The choice is rarely about picking just one strategy. Modern frameworks, including the ecosystem we'll be using, allow you to mix and match these patterns on a per-page basis. The key is to analyze the specific requirements of each part of your application.
This table summarizes the core trade-offs:
| Metric | Client-Side Rendering (CSR) | Server-Side Rendering (SSR) | Static Site Generation (SSG) |
|---|---|---|---|
| Initial Load (FCP) | Slow | Fast | Fastest |
| Time to Interactive (TTI) | Can be slow (bundle size) | Can be slow (hydration) | Fast |
| SEO | Poor | Excellent | Excellent |
| Data Freshness | Real-time | Real-time | Stale (at build time) |
| Server Cost | Low (for rendering) | High | Very Low |
| Infrastructure Complexity | Low | High (Node.js server) | Low (Static hosting/CDN) |
To see how these trade-offs play out in practice, let's look at some real-world architectural decisions.
Understanding SSR, SSG, ISR, CSR with Examples
The following article, 'Understanding SSR, SSG, ISR, CSR with Examples,' provides excellent, concrete examples of how to apply these rendering strategies to different types of large-scale applications.
Please read the section titled 'Real-World Scenarios'. It breaks down how you might architect an E-commerce platform, a News Website, and a SaaS Dashboard using a hybrid of these rendering techniques.
Tying it to Your Experience
After reading those scenarios, take a moment to reflect. Consider a complex application you've led, for instance at Bookmate or Lazada.
- Which specific pages or features were pure CSR and might have benefited from SSR for better SEO or initial load performance (e.g., product detail pages, article pages)?
- Were there any sections of the site that were mostly static and could have been prime candidates for SSG (e.g., marketing landing pages, documentation, blog posts)?
This thought process—analyzing a page's requirements for data freshness, interactivity, and public visibility—is exactly the skill we are honing in this lesson.
Conclusion
We've established a clear framework for analyzing rendering architectures. Here are the key takeaways:
- Client-Side Rendering (CSR) is ideal for highly interactive, private, or app-like interfaces (e.g., dashboards, user settings) where initial load time and SEO are less critical.
- Server-Side Rendering (SSR) is the go-to for pages that require both up-to-the-minute dynamic data and strong SEO (e.g., e-commerce product pages, social media feeds).
- Static Site Generation (SSG) offers unbeatable performance and cost-efficiency for content that changes infrequently (e.g., blogs, documentation, marketing sites).
Your goal as an architect is not to choose one "best" pattern, but to select the right pattern for the right job, often within the same application.
In our next lesson, we will dive into a crucial mechanism that makes modern SSR possible with frameworks like React: hydration. We'll explore what it is, how it works, and how to diagnose the common "hydration mismatch" errors that can occur when the server-rendered HTML doesn't perfectly match what the client-side React code expects to render.