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.

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)
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?
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
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/