Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Isomorphic applications

Isomorphic applications

There is no such thing as separated client and server app in the isomorphic era, there are only environments (browser, server, IoT device etc.). One app is running on both client and server side: this the end of the SEO pain and code duplications.

1e2275ae49fccaa79d88fa6539492640?s=128

Peter Marton

June 18, 2015
Tweet

Transcript

  1. Isomorphic Applications Peter Marton @slashdotpeter

  2. $ whoami - work: RisingStack, Inc. - twitter: slashdotpeter -

    email: peter@risingstack.com - blog: http://blog.risingstack.com
  3. Isomorphic JavaScript “JavaScript code that can be shared between environments.”

    - Spike Brehm
  4. function sum (a, b) { return a + b; }

  5. Why do we need to go isomorphic?

  6. SPA: Single Page Load Applications - single page load -

    pure data after first load -> fast UI - renders on client side - example: Backbone, AngularJS, etc.
  7. BUT (there is always a but)

  8. None
  9. SPA Problems - SEO - code duplications: validation, routing... -

    performance - first load is heavy -> bandwidth - rendering (CPU intensive) -> drains mobile battery - legacy browser support
  10. Ideal world === ?

  11. 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
  12. Isomorphic app

  13. What can be common?

  14. None
  15. One application

  16. One codebase

  17. One team

  18. same sh*t bug, everywhere ;)

  19. What can be shared? - from templates and small components

    - to the ~entire application - today I talk about entire apps
  20. Isomorphic JavaScript “JavaScript code that can be shared between environments.”

    - Spike Brehm
  21. Different environments IoT device node.js server mobile app browser

  22. Environments are different - different platforms: server, browser etc. -

    different features - different JavaScript engines - different inputs and outputs
  23. Example inputs - Temperature sensor - GPS - API response

    - Mouse click
  24. Example outputs - LED blink - Speaker - API request

    - DOM render
  25. Differences need to be shimmed - common interface - different

    implementation - example: Instead of file read -> API req, sensor read
  26. What is shim/polyfill? - application compatibility workaround

  27. None
  28. 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]'; }; }
  29. Environment differences and/or different JS engines

  30. 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
  31. Node.js: libuv - multi-platform - support library - asynchronous I/O

    - TCP, UDP, file system etc.
  32. V8 JavaScript Engine - C++ - implements ECMAScript - used

    in Chrome and Node.js - by Google
  33. Core modules - useful functionality - implemented in JavaScript (most

    of them) - event, stream, util etc.
  34. Node.js: V8, libuv, core modules + core +

  35. Chrome: V8, blink (WebKit fork) +

  36. V8 is common others should be shimmed

  37. libuv feature shim - differences like: TCP socket read -

    doesn’t exist in browser - should be shimmed - TCP socket read -> data input -> HTTP request
  38. Node.js core module shim - implemented in JavaScript (stream, event…)

    - bundle and import - use in Browser with Browserify / Webpack - from NPM as well
  39. JavaScriptCore (iOS) in nutshell - Objective-C / Swift wrapper -

    around WebKit's JS engine - no more WebView - used by React Native
  40. 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...
  41. DOM shim example - when there is no DOM ->

    (server: Node.js, JavaScriptCore) - DOM -> virtual DOM - React for example - server side rendering
  42. Isomorphic webapp

  43. 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
  44. Isomorphic challenges - environment shims - able to create instances

    from your app - avoid sharing of personal data - technology in early phase
  45. What do we need?

  46. 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...
  47. 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
  48. App is a function, state is a state myApp (state)

    { return <div>{state.name}</div>; } - easy to serialize - app response for data - no side effects
  49. How does it work?

  50. Isomorphic codebase, lifecycle

  51. Isomorphic server side

  52. Isomorphic client side

  53. data-reactid

  54. Showcase 1/2 brew-ui

  55. Isomorphic charts - charts can be isomorphic as well -

    with SVG yet - http://viget.com/extend/3474
  56. Showcase 2/2 server rendered charts

  57. Q&A Thank you! http://blog.risingstack.com/from-angularjs-to-react-the-isomorphic-way/