Hasty Treat - React Server Side Rendering

Episode Summary

Executive Summary: The episode explains server-side rendering (SSR) in React, contrasting it with client-side rendering and covering why teams use it: SEO, performance, and metadata support. Wes and Scott walk through how SSR works in frameworks like Next.js and Gatsby, the hydration process, common pitfalls (window, useLayoutEffect, data fetching, localStorage), and practical tools such as Apollo helpers and no-SSR wrappers.

Main Topics: What SSR is vs. client-side rendering: The hosts define traditional server rendering, compare it to CSR in React apps, and explain hydration as the step that turns server HTML into an interactive client app. Why SSR is used: They emphasize SEO for crawlers that struggle with blank client-rendered pages, plus faster first paint because HTML can be delivered before JavaScript finishes loading. Frameworks and rendering models: Next.js is described as runtime SSR on request, while Gatsby is framed as build-time/static generation. They note many other stacks can implement SSR, but the tooling is less convenient. SSR gotchas in React: They discuss server-only limitations: no window, useLayoutEffect errors, localStorage/auth issues, and the challenge of making browser-dependent code safe on the server. Data fetching complexity: The episode highlights that asynchronous data loading is hard to coordinate in SSR, especially for nested components, and mentions Apollo and future React Suspense as solutions. Practical tools and migration strategies: They recommend helpers like Apollo SSR packages, isomorphic fetch, and no-SSR wrappers to gradually convert client-rendered apps to SSR without breaking everything at once.

Key Arguments: SSR is valuable mainly because crawlers and social/metadata consumers need real HTML, not a blank client shell, for SEO and rich link previews. SSR can improve perceived speed by sending pre-rendered HTML immediately, then hydrating it on the client. Next.js is better suited to dynamic, request-based SSR, while Gatsby fits static or brochure-style sites because it builds HTML ahead of time. SSR is much harder than “just use Next.js” suggests because browser-only APIs like window, localStorage, and even useLayoutEffect can break on the server. Data fetching is the hardest part of SSR because component-level async data must be coordinated before render, often requiring framework-specific helpers. A gradual migration strategy is to disable SSR for problematic components first, then re-enable SSR piece by piece as issues are fixed.

Data Points: Sentry free trial offer: 2 months free - Promo code "tasty treat" for Sentry. Episode reference: Episode 127 - Referenced as a prior episode about React Suspense. UseLayoutEffect workaround: 1 custom pattern - They describe an isomorphic layout effect that swaps to useEffect when window is undefined. SSR migration approach: Step-by-step component rollout - They describe starting with a no-SSR wrapper around the whole app and gradually removing it from components.

Pivotal Quotes: "If a robot or somebody that's not a person is crawling your site and trying to get some data out of it... that is a big use case." — Scott: Explaining SEO and metadata as major reasons to use SSR. "There's a whole bunch of gotchas. So, the first one here is that there's no window." — Scott: Introducing the main server-environment limitations developers run into. "I can't wait for suspense to come because I think it's going to make a lot of this really, really easy." — Wes: Closing optimism about React Suspense simplifying SSR and data loading.

Implications: For developers, SSR offers better SEO and faster first render, but it demands careful handling of browser-only APIs and async data. The future likely gets easier with Suspense and better framework abstractions.