React SSR, SSG, SPA - History & Colour

readme.md

SSR History & Colour

• Three React approaches
  • SPA Single Page Applications
  • SSR Server Side Rendering
  • SSG Static Site Generation

  • SPA - Single Page Applications :: fat client, API
    • Send plain javascript that does on everything on client
    • SEO nightmare
      • Google Crawler is starting to execute JavaScript
      • Page performance still matters
    • Slow first load, but also sometimes, slow every time
    • A lot of JavaScript
      • Network cost
      • Parsing cost (mobile)
        • iPhones: Fast CPUs, unoptimised JavaScriptCore engine
          • Same engine as in React Native. Hermes solves this
        • Android: Slow CPUs, optimised JS engines
    • Logged-in/non-indexable desktop web apps
    • create-react-app

  • SSG - Static Site Generation :: html files on disk
    • JAMStack - JavaScript, APIs, Markup
    • Gatsby, react-static, (eleventy, many non-react projects)
    • Websites like we used to love them
      • Incredible scaling, serve from S3 or cache @ edge
    • Have to rebuild website when data change

  • SSR - Server Side Rendering :: ruby on rails
    • Ok for websites
    • Good for indexable, dynamic web applications
      • Or a performance optimisation over SPA
    • SSR historically
      • HTML + Progressive enhancement
      • Some kind of templating engine (Handlebars, Jinja, Liquid…)
      • Developer experience pretty slow for dynamic apps
    • SSR in React
      • Isomorphic Universal
    • Best/worst of both worlds
      • Good performance, accessibility
      • Need to scale servers
        • Need caching layer in front
        • Serverless helps with DevOps
        • Lambda@Edge/CloudFlare workers a possible future strategy

• SSR performance characteristics
  • TTFB is slow - Technical metric, not user metric
  • TTFCP is fast - Time to First Contentful Paint
  • TTI - Time to Interactive (thanks to rehydration) can be very slow
  • https://github.com/GoogleChrome/lighthouse-ci

• SSR approaches
  • Next.js
    • getInitialProps
      • Walk the tree
      • Get the data
      • Re-render with data
  • Razzle
  • https://reactjs.org/docs/react-dom-server.html
    • renderToString
    • renderToStaticMarkup — same as toString, but no react-ids etc. for rehydration
    • renderToNodeStream() — helps with TTFB
    • renderToStaticNodeStream()
  • Some experiments
    • Dale: https://github.com/FormidableLabs/rapscallion
  • Big challenge: Data fetching and (CSS-in-JS) style hydration
    • There on thing Node is bad at it’s CPU intensive workloads
      • String parsing/stringifying
      • Tree walking
      • https://github.com/ctrlplusb/react-tree-walker
    • Two-pass rendering
    • React app is a tree, it needs to be walked
  • https://github.com/ctrlplusb/react-tree-walker
    • React Suspense helps with this
      • Not ready yet
      • Phil: https://github.com/FormidableLabs/react-ssr-prepass

• FB <> SSR
  • Historically FB didn’t do SSR
  • The new Facebook.com/Comet/FB5 will be using JavaScript SSR (Node-like, but not node)
  • React SSR
  • React Suspense is blocked by this
  • Future is bright but uncertain