The document discusses the concept of isomorphic JavaScript or universal JavaScript, highlighting the benefits of server rendering combined with client-side rendering for optimal web applications. It reviews the history, limitations, and advantages of isomorphic JavaScript, such as improved SEO and user experience, while emphasizing the importance of using the right tools for web development. Additionally, it mentions various implementations and case studies showcasing the adoption of this approach in popular applications like Netflix and Airbnb.

1. Isomorphic JavaScript –
future of the web
Sugak Alexandr

2. Example
• For examples go to http://react.rocks/tag/Isomorphic

3. A little bit of History
• Server rendering:
- Mostly static markup;
- Load is on the server:
- Pages, not apps.

4. A little bit of History
• Server rendering:
- Mostly static markup;
- Load is on the server:
- Pages, not apps.
• Single Page Apps (client rendering):
- Started with apps like GMail;
- Followed by frameworks like Ember and Angular;
- No round-trips, offline mode(if done right);
- Different language on the client and server.

5. Image taken from http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

7. Why not both?
• Initial page rendering on the server;
• Content delivered to the client;
• Progressive enhancement using client rendering;
• Reuse same code as much as possible.

8. Image taken from http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/

9. Limitations
• Use libraries which are not dependent on browser;
• Therefore, no Angular or any other framework using two way data binding (MVP instead of
MVVM);
• Explicit application state – it must be serializable; (Immutability?)
• Avoid “if (browser)” in your code.
• These are not limitations but benefits actually.

10. Good stuff
• SEO friendly: crawlers do not understand your fancy SPAs;
• URL friendly: URIs are pointers to resources on the web, not implementation details of your
favorite MVVM framework;
• Performance of the server: no initial blank page;
• Speed and flexibility of the client: no round-trips, progressive enhancement;
• Caching: use browser cache, it is there for a reason;
• Testing (given app/component state when rendering expect <element>).

11. Why do I care?
• Full-stack developer, not just .Net server guy;
• Learn technology, not frameworks;
“I don’t want to be an “Ember” guy, an “Angular” dev, an “Aurelia” expert. I want to be a web
expert, a messaging expert, a REST expert, a distributed systems expert.”
(c) Jimmy Bogard
• Same patterns I’ve used to: CQRS, Event-driven design;
• Learning more about functional programming, messaging, JavaScript than about React or Flux;
• Right tool for the job: C#/F# for back-end, JavaScript for the front-end;
• True separation of concerns!

12. Where do we draw the line?
• Separate front-end and back-end (logical layers);
• Not client-server (physical layers);
• Back-end: a place for business logic and data, use statically typed language (C#, F#);
• Do provide a RESTful interface;
• Front-end: a place for presentation logic;
• Do use both server and client to provide the best user experience without making compromises;
• JavaScript – language of the web.

13. Isomorphic: is this a good name?
• Original meaning: "any given line of code (with notable exceptions) can execute both on the client
and the server" (c) Charlie Robbins;
• But “isomorphic” means: two entities which are not the same, but look the same (have same effect)
(c) Michael Jackson
• What we mean is: same code but running in the different environments;
• “Universal” means: "applicable to all cases“ or “code that runs everywhere”;
• Other opinion: “Isomorphic” JS is comparable in its effect, but does not need to have the exact
same behavior (c) Matti Schneider;
• Still, no agreement in the community, so google both.

14. Implementations
• Mojito by Yahoo! was one of the first. Vendor-specific quirks, no wide-spread;
• Meteor: huge “do everything” full-stack framework;
• Luna by Asana. Separate copy of the app runs for each user on the server, close-source;
• Rendr by Airbnb: not full-stack, library not framework; Renders Backbone apps on client and
server;
• React by Facebook: not full-stack (but you can use Flux, etc.), library not framework. Huge
community already and growing;

15. My sample implementation
• Based on Yahoo!’s Fluxible library (based on Facebook’s Flux);
• Node.js server + Express.js running Fluxible app;
• React as view engine;
• Fluxible Routr for routing;
• Superagent to connect to back-end API;
• Webpack for bundling;
• API written in C# on ASP.NET Web Api + Owin for hosting.

16. Unidirectional data flow
Image taken from https://facebook.github.io/flux/docs/overview.html

17. Rendering on the server
Http Request
Browser
Server
(Node.JS)
Web Framework
(Express.JS)
Navigate action
(URL)
Navigate Success event
(Route+Params+Handler)
HTML
Handler.render()
(React component)
Http Response
Dispatcher
(Fluxible)
Router
(Fluxible Routr)
Store.handle(event)
Store.emitChange()

18. Rendering on the client (URL change)
State Changed
Browser
History.js
Fluxible Routr
Navigate action
(URL)
Updated Virtual DOM
Handler.render()
(React component)
Updated DOM
React
Navigate Success event
(Route+Params+Handler)
Dispatcher
(Fluxible)
Router
(Fluxible Routr)
Store.handle(event)
Store.emitChange()

19. Rendering on the client (user event)
User event
Browser
React
React Component
Dispatcher
(Fluxible)
Custom action
(data)
Handler Custom event
(Data)
Updated Virtual DOM
Component.render()
Updated DOM
Store.handle(event)
Store.emitChange()

20. Demo

21. Recommended implementation
• Este: a “metaframework”, i.e. number of libraries combined together to provide a full-stack web
application framework used to build isomorphic/universal apps with React;
• Isomorphic by default: server + browser + mobile (react native);
• Immutable app state by default;
• ES 2015;
• Webpack for bundling;
• Localization, meta tags, caching and much more.

22. Case studies
• Facebook: not isomorphic but uses React for comments section and more;
• Instagram web client: not isomorphic but fully written using React;
• Netflix web site: fully rewritten to be isomorphic (Node.js + React);
• Reddit web site mobile version: fully isomorphic;
• Airbnb mobile web site (?); Now mowing to rendering React from Rails app.
• Loveabout.org: awesome new web site for sharing what you love about things, fully isomorphic.


23. Still, a JavaScript on the server!
• ClojureScript: an interpreter of Clojure (functional JVM language) to JavaScript;
• Websharper: an interpreter of F# to JavaScript, Websharper.UI.Next: FRP-like UI handling;
• TypeScript, ES6: things are getting better;
• ASP.NET 5 Node Services: run node functions from ASP.NET (e.g. compile React component
from .Net server process), announced 2 days ago.

24. Links
• http://blog.nodejitsu.com/scaling-isomorphic-javascript-code/ (initial idea)
• http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/ (where it all started)
• https://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/ (front-end
vs back-end, true separation)
• https://medium.com/@mjackson/universal-javascript-4761051b7ae9#.jpwv5tisy
(Isomorphic vs Universal)
• https://medium.com/@MattiSG/no-isomorphic-in-terms-of-topology-describes-the-
relationship-between-a-transformation-applied-1796e69de0e2#.hbfqc1qum (defending
“Isomorphic”)
• http://techblog.netflix.com/2015/08/making-netflixcom-faster.html (case study)
• https://github.com/este/este (toolbox)
• https://weblogs.asp.net/ricardoperes/asp-net-5-node-services (announced 2 days ago)
• http://cycle.js.org/ (looks very promising)