Isomorphic JavaScript – future of the web

Sugak Alexandr

Example

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

A little bit of History

• Server rendering:

- Mostly static markup;

- Load is on the server:

- Pages, not apps.

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.

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

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.

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

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.

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>).

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!

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.

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.

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;

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.

Unidirectional data flow

Image taken from https://facebook.github.io/flux/docs/overview.html

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()

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()

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()

Demo

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.

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.

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.

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)