Isomorphic JavaScript
“JavaScript code that can be shared between
environments.” - Spike Brehm
Slide 4
Slide 4 text
function sum (a, b) { return a + b; }
Slide 5
Slide 5 text
Why do we need to go isomorphic?
Slide 6
Slide 6 text
SPA: Single Page Load Applications
- single page load
- pure data after first load -> fast UI
- renders on client side
- example: Backbone, AngularJS, etc.
Slide 7
Slide 7 text
BUT
(there is always a but)
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
SPA Problems
- SEO
- code duplications: validation, routing...
- performance
- first load is heavy -> bandwidth
- rendering (CPU intensive) -> drains mobile battery
- legacy browser support
Slide 10
Slide 10 text
Ideal world === ?
Slide 11
Slide 11 text
What do we need
- performance (rendering, initial load)
- indexable sites -> SEO
- progressive enhancements out of the box
- server and client side rendering
- eliminate code duplications
Slide 12
Slide 12 text
Isomorphic app
Slide 13
Slide 13 text
What can be common?
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
One application
Slide 16
Slide 16 text
One codebase
Slide 17
Slide 17 text
One team
Slide 18
Slide 18 text
same sh*t bug, everywhere ;)
Slide 19
Slide 19 text
What can be shared?
- from templates and small components
- to the ~entire application
- today I talk about entire apps
Slide 20
Slide 20 text
Isomorphic JavaScript
“JavaScript code that can be shared between
environments.” - Spike Brehm
Slide 21
Slide 21 text
Different environments
IoT device node.js server mobile app browser
Slide 22
Slide 22 text
Environments are different
- different platforms: server, browser etc.
- different features
- different JavaScript engines
- different inputs and outputs
Slide 23
Slide 23 text
Example inputs
- Temperature sensor
- GPS
- API response
- Mouse click
Slide 24
Slide 24 text
Example outputs
- LED blink
- Speaker
- API request
- DOM render
Slide 25
Slide 25 text
Differences need to be shimmed
- common interface
- different implementation
- example: Instead of file read -> API req, sensor read
Slide 26
Slide 26 text
What is shim/polyfill?
- application compatibility workaround
Slide 27
Slide 27 text
No content
Slide 28
Slide 28 text
Browser shim example
ES5.1 Array.isArray()
http://www.ecma-international.org/ecma-262/5.1/#sec-15.4.3.2
if (!Array.isArray) {
Array.isArray = function(arg) {
return Object.prototype.toString.call(arg)
=== '[object Array]';
};
}
Slide 29
Slide 29 text
Environment differences
and/or different JS engines
Slide 30
Slide 30 text
Node.js in a nutshell
- platform with event-driven, non-blocking IO for building
scalable network applications in JavaScript
- JavaScript on server side
- built with:
- libuv + V8 + core modules
Slide 31
Slide 31 text
Node.js: libuv
- multi-platform
- support library
- asynchronous I/O
- TCP, UDP, file system etc.
Slide 32
Slide 32 text
V8 JavaScript Engine
- C++
- implements ECMAScript
- used in Chrome and Node.js
- by Google
Slide 33
Slide 33 text
Core modules
- useful functionality
- implemented in JavaScript (most of them)
- event, stream, util etc.
Slide 34
Slide 34 text
Node.js: V8, libuv, core modules
+ core
+
Slide 35
Slide 35 text
Chrome: V8, blink (WebKit fork)
+
Slide 36
Slide 36 text
V8 is common
others should be shimmed
Slide 37
Slide 37 text
libuv feature shim
- differences like: TCP socket read
- doesn’t exist in browser
- should be shimmed
- TCP socket read -> data input -> HTTP request
Slide 38
Slide 38 text
Node.js core module shim
- implemented in JavaScript (stream, event…)
- bundle and import
- use in Browser with Browserify / Webpack
- from NPM as well
Slide 39
Slide 39 text
JavaScriptCore (iOS) in nutshell
- Objective-C / Swift wrapper
- around WebKit's JS engine
- no more WebView
- used by React Native
Slide 40
Slide 40 text
JavaScriptCore (iOS) shim example
- JavaScriptCore has limited feature set
- no DOM and XHR for example
- can be implemented in Objective-C / Swift
- React Native polyfills: Network, Timers...
Slide 41
Slide 41 text
DOM shim example
- when there is no DOM -> (server: Node.js, JavaScriptCore)
- DOM -> virtual DOM
- React for example
- server side rendering
Slide 42
Slide 42 text
Isomorphic webapp
Slide 43
Slide 43 text
Our goals
- first render at the server (can be forced for others)
- work as SPA after initial render
- can render on both client and server side
- ~one codebase
- handover between client and server
Slide 44
Slide 44 text
Isomorphic challenges
- environment shims
- able to create instances from your app
- avoid sharing of personal data
- technology in early phase
Slide 45
Slide 45 text
What do we need?
Slide 46
Slide 46 text
What do we need? 1/2
- language that runs on both sides: JS ;)
- bundle with Browserify/Webpack
- modules that runs on both sides -> npm: superagent etc.
- view engine that renders on both sides:
- React,
- VirtualDOM...
Slide 47
Slide 47 text
What do we need? 2/2
- share states: Serializable states (stores)
- https://github.com/yahoo/serialize-javascript
- continue at the client from where server left
Slide 48
Slide 48 text
App is a function, state is a state
myApp (state) {
return
{state.name}
;
}
- easy to serialize
- app response for data
- no side effects
Slide 49
Slide 49 text
How does it work?
Slide 50
Slide 50 text
Isomorphic codebase, lifecycle
Slide 51
Slide 51 text
Isomorphic server side
Slide 52
Slide 52 text
Isomorphic client side
Slide 53
Slide 53 text
data-reactid
Slide 54
Slide 54 text
Showcase 1/2
brew-ui
Slide 55
Slide 55 text
Isomorphic charts
- charts can be isomorphic as well
- with SVG yet
- http://viget.com/extend/3474