Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Server Rendered JavaScript Apps

9bf3a766e037b9d5a4da0a6f9d0f4f68?s=47 tomdale
February 11, 2015

Server Rendered JavaScript Apps

A short talk on the whys and wherefores of server-rendered JavaScript apps, presented at ManhattanJS.



February 11, 2015


  1. Server-Rendered JavaScript Apps

  2. Why Client-Side JavaScript? • Fast Navigation • Fast Data Access

    • Rich Interactivity • Coherent Programming Model
  3. Why Server-Rendered? • Consistent Performance • Fast Initial Render •

    Web Crawlers/cURL
  4. Can you get the best of both worlds?

  5. “Progressive Enhancement”

  6. “Progressive Enhancement” • Server render, then add behavior using JavaScript

    • No client-side routing • Complexity increases over time
  7. Complexity grows exponentially with each new feature.

  8. Progressive enhancement (as a technique) is dead.

  9. But what if we could get the benefits of progressive

    enhancement as a by-product of modern development?
  10. FastBoot

  11. It doesn’t replace your existing server. Point of Clarification

  12. JSON data GET /api/posts.json GET /posts Browser CDN JS App

    Empty HTML, JavaScript (Big!) API Server
  13. Initial HTML JSON data GET /posts Browser FastBoot First Page

    API Server JavaScript JS App
  14. Demo

  15. github.com/tildeio/ ember-cli-fastboot

  16. Next Up: Rehydration

  17. Rehydration • Show server-rendered HTML • Wait for JavaScript to

    load • JavaScript “takes over” once loaded • Side effect: Wicked fast re-renders (thanks to “virtual DOM”)
  18. Thank You