Universal Applications with Stepan Parunashvili OVERVIEW One of the largest issues with building rich client-side applications is the inevitable sharing of logic, as well as performance issues that arise after the initial beta phase is passed. We’ve done well to choose cohesion over a separation of technology with React, and we can go a step further with building Universal Applications (also called ‘Isomorphic Applications’). Here we will discuss building universal apps with React, Redux, and Node.js. From sharing small bits of logic, to sharing the entire application runtime, we will see first how to do it, and the benefits it has for engineering, reusability, performance and SEO. OBJECTIVE To show the watcher when and how to build universal applications. TARGET AUDIENCE Front-end or Full-stack engineers, with a background on React ASSUMED AUDIENCE KNOWLEDGE Medium understanding of Javascript, at least beginner understanding of React AUDIENCE MEMBERS WILL LEARN -What are Universal Applications When to build one — separating their actual benefits from the hype How to go about building a simple skeleton What the potential complexities are when sharing code between different environments

1. Universal Applications
Stepan Parunashvili
1

2. @stopachka
www.stepanp.com
2
Who am I?

3. @stopachka
www.stepanp.com
3
Who am I?

4. Universal Applications
4

5. Isomorphic?
5

6. 6

7. 7

8. 8

9. Isomorphic
9

10. Universal
10

11. 11

12. ...2015
12

13. ...2014
13

14. ...2013
14

15. ...2012
15

16. ...2011
16

17. ...2010
17

18. ...2009
18

19. 2008
19

20. 20

21. 21
v2.2.2

22. 22

23. 23

24. 24
javascript?

25. 25
javascript

26. 26

27. 27
routing
validation
views

28. 28
routing
validation
views
c00l
animations

29. 29
routing
validation
views
c00l
animations
(in some browsers...b^.^d)

30. 30

31. 31

32. 2009...
32

33. 2010
33

34. 34

35. 35
v0.1.0

36. 36

37. 37

38. 38

39. 39

40. 40
routing
validation
views

41. 41
...routing
...validation
...views
routing
validation
views

42. 42

43. 43

44. 44

45. is it just the way things are?
45

46. 46

47. 47

48. 48
routing
validation
views

49. 49

50. 50
what if we made our own
representation of the dom...

51. ...React!
51

52. win 1:
code sharing
52

53. win 2:
perceived performance
53

54. win 3:
SEO
54

55. Can we build this?
55

56. *rolls up sleeves*
56

57. 57
server.js

58. 58
server.js

59. 59
server.js

60. 60
server.js

61. 61

62. 62

63. 63
server.js

64. 64
server.js

65. 65
server.js

66. 66

67. Time to react
67

68. 68
components.js

69. 69
server.js

70. 70
server.js

71. 71
server.js

72. 72
server.js

73. 73

74. 74
components.js

75. 75
components.js

76. 76
components.js

77. 77

78. 78
server.js

79. 79
server.js

80. 80
server.js

81. 81
load client side react
client.js

82. 82

83. ...Now the views are shared
83

84. What's the catch?
84

85. build tools
(webpack, babel & family)
85

86. Time to route
86

87. 87
client.js

88. ReactRouter
88

89. 89
server.js

90. 90
server.js

91. 91
components.js

92. 92
load client side react
components.js

93. 93
load client side react
routes.js

94. 94
load client side react
client.js

95. 95
load client side react
client.js

96. show it working
96

97. 97

98. 98

99. disable js
99

100. 100
server.js

101. 101
server.jsserver.js

102. show it working
102

103. How about data fetching?
103

104. 104
api.js

105. 105
api.js

106. 106
components.js

107. 107
server.js

108. 108
server.js

109. 109
server.js

110. 110
server.js

111. 111
server.js

112. 112
client.js

113. 113
client.js

114. 114
client.js

115. 115
client.js

116. ...but there's a library for that
116

117. react-resolver
117

118. is it all rosy?
118

119. not really
119

120. but the payoff?
120

121. 121

122. 122

123. 123

124. 124
routing
validation
views

125. wait...
single-threaded backend?
125

126. Clojurescript anyone?
126

127. that's it : )
127

128. Questions?
128