Isomorphic Web Apps
with React
Don’t we have solutions for SEO with
single page apps already?
Is server rendering necessary?
https://developers.google.com/webmasters/
ajax-crawling/docs/specification
The Google AJAX
Crawling Spec
“Server Rendering”
App
Server
Prerender
Intarwebs
Amazon S3
“Yak shaving is what you are doing when
you're doing some stupid, fiddly little task
that bears no obvious relationship to what
you're supposed to be working on, but yet a
chain of twelve causal relations links what
you're doing to the original meta-task.”
- Jeremy H. Brown. http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-
11.html
Server Rendering with React
App
Server
Intarwebs
● Design your URLs first, they are important.
● Choose libraries that work in node and the
browser
● Use CommonJS and a module bundler
Core Architecture
Fetching data is typically an
asynchronous process.
React.renderToString is a
synchronous process.
React.render vs React.renderToString
getInitialState
componentWillMount
shouldComponentUpdate
componentWillUpdate
render
componentDidUpdate
componentDidMount
componentWillUnmount
getInitialState
componentWillMount
render
Initial Render
Server
React.renderToString(App(data))
Browser
React.render(App(data))
HTML, JSON.stringify(data)
Demo
https://github.com/larrymyers/react-isomorphic-demo

Isomorphic web apps with react

Editor's Notes

  • #2 “Isomorphic” - fancy way of saying that a javascript application can run on the client or server to render. React is currently the only js framework with server side rendering baked in as a core feature. (Ember.js fastboot is still in development, AirBnB has moved away from Rendr to React.) React server rendering allows us to create crawlable web apps while undoing years of hacks due to technology mismatches between the browser and the server. Allows us to take advantage of deferring as much as possible at page load since the content is already rendered.
  • #4 Googlebot translates the hash url to a querystring to request page state. Expected that the server will render the client app and send back the rendered markup. Businesses spun up around this: prerender.io, brombone This is a lot of extra infrastructure.
  • #5 No explicit documentation yet about how much javascript the googlebot executes, how long it will wait for async operations, etc. SEO with static html has much more existing knowledge and research already available, and is what all search engines do by default.
  • #6 Prerender can introduce significant latency into the rendering process. Caching prerendered pages solves the latency problem, but introduces potential for stale content. Managing caches and cache expiry introduces lots of complexity.
  • #7 Time spent setting up a prerender process is time not spent working on your actual application.
  • #8 Allows us to go back to how web apps have always worked, without having a technology split that requires duplicating code on the client and server.
  • #9 Both browserify and webpack have good solutions for bundling React and integrating with react-tools for jsx transformation. Choose which ever tool you’re most comfortable with. You don’t necessarily need to use a router with React, but it will help.
  • #10 You must gather all necessary data before rendering app. Easiest way to keep this simple is to have skinny route handlers, fat services.
  • #12 If using a Flux library just requires prepopulating your Stores with the proper data before calling React.renderToString.