This document discusses server and client rendering of single page applications. It outlines a wish list tool that was built to track products, receive alerts, and share lists. The goals are to improve the UI, separate the wish list into microservices, and update the frontend using modern frameworks. Shared rendering concerns between server and client are discussed, along with an architecture using Node.js, Express, Backbone, Handlebars and other technologies. Challenges with routing, data fetching, caching and other areas are covered, as well as potential solutions like React and Rendr. Overall it was found to be worthwhile but still immature, requiring better frameworks.
4. GOALS & OBJECTIVES
• Improve UI
• Pull out wish list into separate stack of services
• Update front-end code using modern frameworks and best practices
– Perfect candidate for SPA due to mutability
• Minify duplication which led to inconsistencies
6. • Developers get DRY and MV*
• Users get best of both worlds:
– fully rendered pages (instant content)
– responsiveness of SPA
• Business gets SEO
• Everybody’s happy 🌈😃🎉
ENVIRONMENT AGNOSTIC
7. • EvenThoughtWorks agrees 👌
TECH RADAR
http://www.thoughtworks.com/radar/#/techniques
Client and server rendering with same code
Increasingly, HTML is rendered not only on the server but also on the client,
in the web browser. In many cases this split rendering will remain a necessity
but with the growing maturity of JavaScript templating libraries an interesting
approach has become viable: client and server rendering with same code.
HOLD ASSESS TRIAL ADOPT
21. • Lots of code bridging differences between environments and libraries
– Introducing extra abstraction layer
• Routing is different
– Stateless server-side routing (new app instance for each request)
– Stateful client-side routing (holding on to app during page navigation)
– Express vs. Backbone routes (reversed order, paths, params)
– Redirects (302 vs. browser location)
– Serve mobile page based on user agent
• Fetching data is different (XMLHttpRequest vs. node request)
COMPLEX PROBLEM
22. • Caching is different
– Only ever fetch once per incoming request
– Tab could be left open for days
– Expire and re-fetch resources after x seconds client-side
• Error handling is different (HTTP error codes vs. popups)
• Sending email is borderline
COMPLEX PROBLEM
23. • Dependency management
– CommonJS runs client-side with browserify
– AMD runs server-side with require.js
– Both work but ideally language level support (ES6 Modules)
• Promises
– Q or jQuery Deferred
– Ideally one standard (ES6 Promises)
ES5 IMMATURITY
24. • Well known jQuery API for DOM manipulation and traversal
• Easy to pick up
• Can translate Backbone apps directly to the server
• No full blown JSDOM, but still slow
CHEERIO
25. • Airbnb Rendr
– One stop solution (Rendering, Serialization, Routing)
– Pure string concatenation using templates – Fast on the server
– Client-side rendering trashes and re-renders whole DOM (can cause
flicker and performance issues)
• Facebook React
– View rendering library (Bring your own MC)
– Virtual DOM approach: slow on the server but super fast client-side
– Fun fact: Inspired by DOOM III
CHEERIO ALTERNATIVES
26. Rendering comment box with 1000 comments
SERVER-SIDE PERFORMANCE
• Very simple HTML – String concatenation will shine even more as markup
grows in complexity
• React has the edge over Cheerio – JSX uses precompiled objects so can be
heavily optimized byV8 (Cheerio parses strings into trees on runtime)
RENDR
REACT
CHEERIO
~ 110 ms
~ 174 ms
~ 204 ms
27. • Load performance means time to content (not response time)
– Server-side DOM is slow but faster than serving empty pages
• Think of it as an enhancement to SPA
– Stateless service can be easily scaled up
– Respond with empty pages if load is too high and render client-side
• Client-side rendering performance equally important
• Decide per use case – In certain situations simple Express.js templating with
separate client-side JS might be better approach
SO WHAT?
28. • YES! 🌟😺✨
• Joy to develop once hard work is done
• Easy and fast to build rich UI and add new functionality
• But:
• Technique in its infants
• Better frameworks/solutions required
WORTH IT?