Next.js vs Traditional SPA Data Flow Comparison

• Traditional SPA (Vite/Create React App) flow:
  • User receives empty HTML with JS tag
  • User loads JS from tag
  • JS runs, starts fetching data and creating page
  • Data returns, JS finishes rendering page
  • Complete page with correct HTML achieved
  • Requires 3 separate requests: HTML → JS → Data
• Next.js SSR flow:
  • User requests page (e.g., /user/theo)
  • Next server gets request, runs getServerSideProps
  • getServerSideProps fetches data from database using query params
  • React runs on server using properties from getServerSideProps
  • Server sends correct HTML to user based on React render
  • User loads HTML then loads JS to "catch up" (hydration)

Server-Side Rendering Benefits and Mechanics

• Correct initial HTML: Content visible immediately without JS loading
• SEO/metadata advantages: Robots, crawlers get meaningful content
• Performance: Users see content while JS loads in background
• Hydration process: JS recreates same HTML in virtual DOM to enable interactivity
  • Takes roughly same time as client-side rendering
  • Page already visible and readable during hydration
• Data injection hack: Next.js embeds getServerSideProps data in HTML via <script id="__NEXT_DATA__"> tag
  • Necessary for client-side hydration to match server state

Static Generation vs Server-Side Rendering

• Static pages: No getServerSideProps = Next.js generates HTML at build time
  • Served from CDN as static assets
  • Significantly faster, cheaper
  • Better for robots/crawlers
  • Less powerful devices can load easily
• Dynamic pages: With getServerSideProps = HTML generated per request
  • Slower but allows personalized content
  • Server code runs on every request

Server-Side Rendering Limitations

• Code restrictions: Can't run client-only code on server
  • No window object access
  • No local storage
  • No user device APIs (camera, microphone)
  • No stateful code (onClick, setState)
  • No media queries
• Conditional rendering: Works if data comes from server (cookies, database)

Next.js as Enhanced SPA Framework

• Key insight: Next.js IS a single-page app framework
• Only difference from traditional SPA: Initial HTML is correct vs incorrect
• After hydration: Behaves exactly like normal React app
• Timeline comparison:
  • Request → HTML loads → JS loads → JS synced with HTML
  • Next.js: Correct HTML from start
  • Traditional SPA: Incorrect HTML, requires JS to fix
• Performance: Static Next.js pages load same speed as SPA
  • Dynamic pages may be slower for first paint but faster overall
  • Eliminates multiple round trips for data

Real-World Application Examples

• Ping application: 2.5 hour average session time
  • Uses Next.js for highly interactive app
  • Benefits from server rendering for metadata/SEO
  • Dashboard pages don't need server rendering
  • Call pages require JS for A/V functionality but still server render for metadata
• Use cases for client-only: Pages requiring device APIs, exclusive fast internet users
• Use cases for SSR: Any page needing correct metadata, SEO, or accessible content

Framework Philosophy

• Next.js advantages: Server rendering + SPA benefits combined
• Developer experience: Better build tools, API routes, incremental static regeneration
• Flexibility: Can opt out of server rendering per page
• Future-proofing: Most projects eventually need server rendering capabilities