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.

Peter Marton

June 18, 2015
Tweet

More Decks by Peter Marton

Other Decks in Programming

Transcript

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

    pure data after first load -> fast UI - renders on client side - example: Backbone, AngularJS, etc.
  2. SPA Problems - SEO - code duplications: validation, routing... -

    performance - first load is heavy -> bandwidth - rendering (CPU intensive) -> drains mobile battery - legacy browser support
  3. 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
  4. What can be shared? - from templates and small components

    - to the ~entire application - today I talk about entire apps
  5. Environments are different - different platforms: server, browser etc. -

    different features - different JavaScript engines - different inputs and outputs
  6. Differences need to be shimmed - common interface - different

    implementation - example: Instead of file read -> API req, sensor read
  7. 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
  8. libuv feature shim - differences like: TCP socket read -

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

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

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

    (server: Node.js, JavaScriptCore) - DOM -> virtual DOM - React for example - server side rendering
  13. 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
  14. Isomorphic challenges - environment shims - able to create instances

    from your app - avoid sharing of personal data - technology in early phase
  15. 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...
  16. 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
  17. 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
  18. Isomorphic charts - charts can be isomorphic as well -

    with SVG yet - http://viget.com/extend/3474