The document outlines the evolution of server-client architectures, highlighting the progression from traditional server-driven pages to the adoption of modern frameworks like Node.js and React. It emphasizes React's unique role in handling views and managing state with the virtual DOM, while also discussing server-side rendering and the integration of various tools to create isomorphic applications. The conclusion advocates for the flexibility offered by the React ecosystem over traditional frameworks, suggesting that server and client-rendering can coexist harmoniously.

1. Breaking the Server-Client
Divide with Node.js and React
Dejan Glozic, Full-Stack Architect, IBM Cloud Data Services
2015 Programming Layer

2. About Me
IBM Canada Toronto Lab
Full-Stack Architect
IBM Cloud Data Services
@dglozic
http://dejanglozic.com

3. What I Work On

4. Part 1
Brief history of the server-client wars

5. First there was only server
It sent pages with text, hyperlinks and images back to the browser.

6. Then we started running code
Great improvement, pages started coming back tailored to the user and request.

7. Then came Ajax
Microsoft (yes, Microsoft) added XMLHTTPRequest.
JJG called this Ajax (I don’t even).

8. Then came the frameworks
Because spaghetti is great with meatballs, less great with jQuery.

9. It’s not done until it’s overdone
‘Extreme Ajax’
desktop != server != client

10. 2012, Twitter: Server is good!
Pendulum swings back, because ‘time to the first tweet’ is less when server helps.

11. 2013: Node.js extends UI tier
Nicholas Zakas says: UI is now client + Node.js server

12. 2013: airbnb coins ‘Isomorphic’
Then it creates rendr (Keynote spell checkr throws a hissy fit)

13. 2014: React takes off
Yes, it was released in 2013 but you could not shut up about Angular then.

14. 2015: React is Hot
Also, a bunch of nerds get together at a Toronto conference to talk about all this.

15. Part 2
Just enough React to make you dangerous.

16. Don’t compare React to
Angular.
React is just for views. You need router, model and event layers.

17. It assumes life is short
You (and others) should know what your code does 6 months from now.

18. It does not make you feel stupid
<todo-cmp [model]="todo" (complete)="onCompletingTodo(todo)"></todo-cmp>

19. When the state changes, render
That’s it. Seriously.

20. Virtual DOM is the key
React diffs virtual and real DOM, applies delta only.

21. Virtual DOM in other contexts
Server rendering, React Native.

22. Flux+React
Dispatcher
Data Store
ViewServer ActionAction

23. Part 3
In which we meet react-router and react-engine
JS

24. Flip the fake pages
Because we are really just showing and hiding divs

25. Boxes inside other boxes
A
B
C
Route: /A/B/C

26. React Express views
Virtual DOM can render into a buffer - or an Express response.

27. react-router is JavaScript
And Node.js can run JavaScript on the server. Hmm…

29. Meet react-engine
Blend server and client using React, Express, react-router and web pack

30. View
All together now
react-
router
View react-engine
server.js
react-engine
client.js
react-
router View
View
Server Client

31. Part 4
Demo + code review, first attempt

32. How To Follow
• Source code on GitHub: http://github.com/
dglozic/react-engine-demo
• Hosted on Bluemix: http://react-engine-
demo.mybluemix.net

33. Part 5
Once again, this time for the real world

34. Remember this page?

35. Not everybody uses React
Need a compromise UI composition solution for the uber-system.

36. Dust.js to the rescue
Header (HTML/CSS/JS)
Page content (React)
Nav
(ditto)
Microservice 1
Microservice 2 Microservice 3

37. Let’s try again
• Source code on GitHub: https://github.com/dglozic/
fsto2015-demo
• Hosted on Bluemix: http://fsto-2015-
demo.mybluemix.net/

38. Conclusion
Isomorphic apps FTW

39. Server or client rendering? Yes!
There is no need to choose sides any more.

40. Initial server rendering
Instant browser content, automatic SEO

41. Client mount
Server-rendered state is not lost

42. Client takes over
All the virtues of client side JS, guilt-free

44. Yes, I know about Meteor
We prefer flexibility of React ecosystem to ‘full framework’ lock-in of Meteor

45. React community hedge
Our full stack consists of multiple libraries, reducing single vendor risk

46. Q/A
?

47. Thank you!
Follow me on Twitter: @dglozic
Read my blog: dejanglozic.com
2015 Programming Layer