This document discusses isomorphic JavaScript, which refers to code that can run both on the server during rendering and in the browser.
It notes some key libraries like React that enable isomorphic code by allowing the same code to render markup on both the server and client. It also discusses pushing inconsistencies between the server and client environments up to higher levels of code or down into common libraries.
The document demonstrates how to set up a basic isomorphic JavaScript project using Webpack and React, and discusses the perspectives of library authors and application developers in building isomorphic code.
2. AKA • Isomorphic
• Universal
– Not to be confused with a
Universal Module
• Portable
3. Isomorphic
JavaScript
• Narrowly: Same Code
Renders Markup on
Server and Client
– React, Rendr, Meteor
• Broadly: CodeThat Is At
Home on the Server and
the Browser.
– Superagent, lo-dash, Q
Presented by FamilySearch
5. Libraries
Built on
Common
Ground
• The community already
has interest in creating
libs built on common
ground and easily loaded
in the browser or node.
– Ex: Q, underscore/lodash,
moment.js, Chai
6. Inconsistencies
In the Browser
• XMLHttpRequest()
• DOM
• Local storage et al.
In Node
• http.request()
• None/Replacement (React)
• Files and databases
Presented by FamilySearch
8. Pushing
Inconsistency
Up
• Make your caller deal with
it
• Accept the fruits
– Example: use a hierarchy of
React components. Only at the
top do you differentiate
between React.render() and
ReactDomServer.renderToString().
9. Pushing
Inconsistency
Down
• Make a dependency deal
with it
• Interact with a façade
– Example: Have a service that fetches
data. Consumers act like data is
fetched uniformly. Under the covers
it uses different URLs inside the data-
center versus outside the firewall.
11. Detect and
Differentiate
• if (typeof window ===
‘undefined’) you’re on the
server, bub.
• Can add sentinels,
depending on your
control
12. Packaging • Pick something that lets
you transparently use
modules in node or in
Browser.
– WebPack is gaining popularity
– Browserify does the job, too
14. Setting up
WebPack
(with React)
• Check out Radu Brehar’s
instructions at
http://jslog.com/2014/10/
02/react-with-webpack-
part-1/
– Some updates in the code at
https://github.com/tylerpeterso
n/isojs
16. As a Lib
Author
• If meant for common use,
you should make your code
into a universal module at a
the minimum. Be kind to
your users.
• Your library might target
one environment at first
and be useful enough to
shim to work in both.
17. As App
Author
• Let’s you write logic once
and run in both places
– Caution: Different concerns on
client and server.
• Many new ideas haven’t
been fully explored
18. React
Changes
Applicability
• I’m using react in my demos
because portable UI
increases the possibilities of
universal JS.
• Now you can push
inconsistency above, below,
or into the UI and still have a
large amount of Universal
JavaScript.
19. Demo:
Rendering
Portability
• Example of rendering
your page entirely on
server or entirely in client.
– https://github.com/DavidWells/i
somorphic-react-example
20. Demo:
Request
Hand-off
• Start all the work on the
server, stream above-the-
fold content, respond to
bandwidth in a beacon
feedback loop, let client
finish up the work.
– https://github.com/tylerpeterso
n/isojs