The Evolution of the "Web App" - FluentConf 2015

Transcript

1. Evolution of the "Web App" @HenrikJoreteg
2. @Hoarse_JS
3. THIS USED TO BE SIMPLE!
4. 1. WRITE SOME HTML 2. LAY IT OUT WITH FRAMES OR TABLES 3. FTP IT TO A SERVER! 4. BAM!
5. CONGRATULATIONS, YOU’RE A WEB DEVELOPER!
6. THEN IT GOT HARDER
7. WHO’S WRITTEN THEIR OWN BLOG SOFTWARE?
8. OVER ENGINEERING A BLOG WAS A RITE OF PASSAGE
9. 1. WRITE SOME PHP/PYTHON/ASP/COLDFUSION 2. SET UP RELATIONAL DATABASE 3. WRITE SOME BAD SQL 4. SHOVE DYNAMIC DATA INTO OUR HTML 5. LAY IT OUT WITH CSS (NO TABLES THIS TIME) 6. RUN IT ON SHARED HOSTING SOMEWHERE
10. CONGRATULATIONS, YOU’RE A WEB DEVELOPER!
11. PHEW!!
12. THEN WE GOT "SMART"
13. USE A FRAMEWORK!!
14. 1. RAILS 2. ALL THEM PHP FRAMEWORKS 3. DJANGO 4. ETC.
15. OUR EXCESSIVLELY DYNAMIC BLOG… IS NOW BETTER ORGANIZED AND HAS MORE DEPENDENCIES
16. CONGRATULATIONS, YOU’RE A WEB DEVELOPER!
17. WHAT ABOUT TODAY?
18. BACK-END FRONT-END ISOMORPHIC RESPONSIVE ES6(2015) BABEL TRACEUR AMD COMMONJS MVC MVVM FLUX RELAY GULP GRUNT API-GATEWAY CORS JSON-WEB-TOKENS NODE.JS HTTP 2.0 OFFLINE-FIRST MOBILE-FIRST WEBGL WEBRTC WEBSOCKET GRAPHQL AMPERSAND EMBER REALTIME REDIS RIAK LEVELDB RABBITMQ PUSH-NOTIFICATION ENABLED BACKBONE APP WITH POLYFILLED POLYMER WEB COMPONENTS
19. CONGRATULATIONS YOU MIGHT BE A "WEB DEVELOPER"
20. WHAT DOES "WEB DEVELOPER" EVEN MEAN?
21. WHAT DOES "WEB APP" EVEN MEAN?
22. THE BROWSER ISN’T OUR RENDERER
23. THE BROWSER IS OUR RUNTIME
24. THE WEBVIEW IS OUR RUNTIME
25. MORE LOGIC MOVING TO FRONT-END JS
26. DEVS WITH DIFFERENT BACKGROUNDS CONVERGING ON JS
27. BRINGING THEIR PATTERNS AND PREFERENCES
28. BACK-END FRONT-END ISOMORPHIC RESPONSIVE ES6(2015) BABEL TRACEUR AMD COMMONJS MVC MVVM FLUX RELAY GULP GRUNT API-GATEWAY CORS JSON-WEB-TOKENS NODE.JS HTTP 2.0 OFFLINE-FIRST MOBILE-FIRST WEBGL WEBRTC WEBSOCKET GRAPHQL AMPERSAND EMBER REALTIME REDIS RIAK LEVELDB RABBITMQ PUSH-NOTIFICATION ENABLED BACKBONE APP WITH POLYFILLED POLYMER WEB COMPONENTS
29. SINGLE PAGE APPS
30. HUH?
31. SINGLE PAGE APPS
32. "NATIVE"
33. I’M A WEB DEVELOPER
34. NATIVE WEB APP
35. 1. JAVASCRIPT 2. HTML 3. CSS 4. BROWSER APIS
36. FUNDAMENTAL DISTINCTION…
37. THE BROWSER IS YOUR RUNTIME
38. SEND THE APP ITSELF TO THE BROWSER INSTEAD OF THE RESULT OF RUNNING IT
39. <!doctype> <script src="app.1.3.7.js"></script>
40. SHOULD WE EVEN BE DOING THIS?
41. SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?
43. SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?
44. {{ RAISE YOUR HAND }}
45. YES!
46. WHAT SERVICE ARE WE PROVIDING?
47. CONTENT?
48. CONTENT SHOULD JUST WORK™
49. NO REASON TO COMPLICATE THINGS THAT CAN BE SIMPLE
50. BUT THE WEB IS NO LONGER JUST ABOUT LINKED CONTENT!
51. THERE ARE CASES WHERE CLIENTSIDE FUNCTIONALITY IS THE CORE VALUE PROVIDED BY SERVICE
56. 1. RENDERING 2. NETWORKING 3. FILE READ/WRITE 4. STORAGE 5. WEB AUDIO APIS 6. WEBGL 7. VOICE/VIDEO HIGH PERFORMANCE
57. BROWSERS ARE NOT DUMB DOCUMENT VIEWERS
58. MOST CAPABLE UBIQUITOUS RUNTIMES ON THE PLANET
59. I’M JUST GOING TO SAY IT:
60. THERE ARE TWO TYPES OF APPLICATIONS ON THE WEB
61. 1. NATIVE WEB APPS
62. 2. SERVER-SIDE WEB APPS
63. THEY ARE FUNDAMENTALLY DIFFERENT
64. AND THAT’S O.K.
65. ANYTHING WE CAN BUILD WITH WEB TECH I THINK WE SHOULD
66. EVEN IF WE CAN’T SUPPORT OLDER BROWSERS
67. THE WEB IS INFINITELY MORE OPEN THAN NATIVE PLATFORMS
68. USER EXPECTATIONS HAVE EVOLVED
69. THE WEB IS DOING PRETTY WELL ON DESKTOPS
70. THE WEB IS LOSING ON MOBILE
71. THE WEB IS LOSING ON EXPERIENCE
72. WE OFTEN PREFER NATIVE APPS TO THE WEB
73. QUALITY AND POLISH OF USER EXPERIENCE IS OFTEN MUCH BETTER
74. LET’S FIX THIS!
75. WE’RE TOO FOCUSED ON THE PAST INSTEAD OF COMPETING ON EXPERIENCE
76. SAYING THERE’S A DISTINCTION MAKES SOME PEOPLE MAD
77. "Everything should be an enhancement!"
78. WE’RE ON THE SAME TEAM!
79. WE WANT THE OPEN WEB TO WIN!
80. HOW COULD WE EVEN BUILD A PROGRESSIVELY ENHANCED VERSION OF TALKY?
81. SHOULD WE NOT HAVE BUILT IT?
82. WHERE’S THE DOWNSIDE?
83. LET’S LOOK A BIT CLOSER AT TWITTER
84. WHAT IS TWITTER?
85. IS IT A WEB APP?
86. NO.
87. IT’S A SERVICE
88. APP != SERVICE
89. TWITTER android app iOS app tweetbot twitter.com tweet deck ad dashboard
90. I DIDN’T REALLY CARE HOW THEY BUILT THEIR WEBAPP
91. BECAUSE I DIDN’T USE IT ANYWAY!
92. I WAS USING AN iOS APP!
93. THEIR WEB APP HAD ALREADY FAILED ME!
94. LET’S THINK ABOUT THIS
95. WHEN I FOLLOW A LINK TO A RANDOM TWEET ON MY PHONE…
96. JUST LET ME READ IT!
97. plain text I DON’T MIND IF IT’S
98. DON’T MAKE ME DOWNLOAD 2MB OF JS TO READ 140 CHARACTERS OF TEXT!
99. THIS IS THE PROBLEM THEY FIXED WITH NEW NEW TWITTER
100. BUT…
101. CATCHING UP WITH ALL THINGS TWITTER IS A FUNDAMENTALLY DIFFERENT USE CASE
102. FAILING TO RECOGNIZE DISTINCTION MAKES US FLOUNDER
103. A SERVICE CAN PROVIDE BOTH!
104. TWITTER.COM & TWEETDECK.COM
105. THERE’S STILL SOME GAPS BETWEEN WEB AND NATIVE
106. REAL OFFLINE SUPPORT
107. PLATFORMS THAT TREAT NATIVE WEB APPS AS FIRST CLASS CITIZENS
108. THOSE THINGS ARE CHANGING
109. 1. SERVICE WORKER
110. PROGRAMMABLE CACHE LAYER CAN INTERCEPTS ALL NETWORK REQUESTS 1. SERVICE WORKER
111. THIS IS HUGE!
112. 2. INSTALLABLE WEB APPS
113. CHROME M39+ FIREFOX https://developer.chrome.com/multidevice/android/installtohomescreen https://w3c.github.io/manifest/ JSON-BASED WEB MANIFEST
114. 1. SIGNAL INTENT 2.UNINSTALL 3.DEEPER DEVICE APIS
115. "What about performance?"
116. WHITE PAGE OF DEATH
117. TIME TO FIRST PAINT
118. A PRIMED CACHE LARGELY INVALIDATES THIS ARGUMENT
119. <!doctype> <script src="app-1.2.7.js"></script> 1. GIVE IT A UNIQUE NAME HTTP/1.1 200 OK Cache-Control: max-age=REALLY BIG NUMBER! Content-Encoding: gzip 2. CACHE IT FOREVER
120. MOST OF THESE TYPES OF APPS REQUIRE YOU TO BE LOGGED IN
121. PRE-FETCH APP ON PUBLIC PAGES OR LOGIN PAGE
122. NATIVE WEB APPS CAN STILL HAVE SMALL JS PAYLOADS!
123. ALL JS IN THE AMPERSAND.JS APP ON TODOMVC.COM COMBINED 28kb min + gzip
124. SMALLER THAN JQUERY 2.0
125. THE OTHER ASPECT OF PERFORMANCE…
126. ONCE LOADED, PERFORMANCE IS WAY BETTER!
127. IF I’M GOING TO LEAVE APP OPEN ON MY DESKTOP I CARE WAY LESS ABOUT LOAD TIME
128. "What about dual rendered a.k.a. isomorphic apps?"
129. JUST A CLIENTSIDE APP WITH AN OPTIMIZED INITIAL RENDER
130. GOING FULL-ISOMORPHIC RENDERING, WITH USER DATA AND ALL…
131. OFTEN REQUIRES DRAMATICALLY MORE COMPLEX CODE
132. THERE ARE SOME CASES WHERE IT MAKES SENSE
133. WITH STATE OF TOOLING TODAY OFTEN NOT WORTH THE COMPLEXITY
134. HOWEVER…
135. DOESN’T HAVE TO BE ALL OR NOTHING
136. WE CAN PRE-RENDER EVERYTHING THAT’S NOT USER-SPECIFIC DATA
137. WE CAN DO THIS AS A FULLY STATIC SITE
138. site.com/pic.png -> pic.png site.com -> index.html site.com/page -> page.html site.com/asdf -> 404.html or 200.html Route: Asset:
139. WOAH!
140. APPS USUALLY HAVE: 1. public/marketing pages 2. all the stuff behind the login
141. WRITE "PUBLIC" PAGES AND APP LAYOUT HTML AS ISOMORPHIC COMPONENTS
142. PRE-RENDER THEM TO STATIC PAGES AT BUILD TIME!
143. SLIP IN THE BUILT JS BEFORE: </body>
144. index.html: public home page 200.html: application layout
145. COULD POTENTIALLY EVEN DO THIS FOR DYNAMIC/PUBLIC DATA
146. THINK ABOUT WHAT WE GET
147. pixels on the screen immediately
148. TOTALLY CRAWLABLE (SEO)
149. JS TAKES OVER ROUTING WHEN LOADED
150. DEPLOYMENT AND OPS BECOME AS SIMPLE AS FTP
151. WRITE 1 VERSION OF YOUR APP GET 90% OF BENEFIT FROM ISOMORPHIC RENDERING
152. USERS WILL END UP WITH A PRIMED CACHE JUST BY VISITING YOUR MARKETING PAGES
153. READY FOR: PHONEGAP/CORDOVA DESKTOP APP
154. NOW WE HAVE AN APP WITH A SINGULAR CONCERN: PRESENTATION
155. I’VE STARTING BUILDING ALL MY APPS AS STATIC NATIVE WEB APPS
156. TOTALLY <3 IT!
157. FOR SO LONG THE TREND HAS BEEN TOWARD COMPLEXITY
159. WHAT’S THE NEXT STEP IN THE EVOLUTION OF THE "WEB APP"?
160. GOING BACK TO SIMPLE
161. GOING BACK TO THE STATIC WEB
162. STATIC NATIVE WEB APPS
163. POWERED BY SERVICES SOME WHICH WE BUILD MANY OF WHICH WE RENT
164. surge.sh hood.ie firebase.com auth0.com divshot.com
165. SIMPLE OPEN SOURCE EXAMPLE: HubTags.com
166. •React •Ampersand.js •Webpack (hjs-webpack) •GitHub API •Surge.sh
167. andyet.com
168. HOW CAN WE BE SURE WE’RE BUILDING WITH THE RIGHT TOOLS?!
169. WE CAN’T!
170. WHAT DO WE KNOW?
171. THINGS WILL CHANGE
172. BUILD MODULAR SYSTEMS THAT STRIVE TO BE AS SIMPLE AS THEY CAN BE
173. OFFLOADING PRESENTATION STATIC NATIVE WEB APPS
174. BUILDING MICROSERVICES TO ENABLE THAT TYPE OF APP
175. OPTIMIZE FOR CHANGE. IT IS THE ONLY CONSTANT.
176. LET’S KEEP PUSHING FOR SIMPLICITY
177. LET’S BUILD FOR THE FUTURE OF THE WEB, NOT ITS PAST
178. THANKS! @HenrikJoreteg, andyet.com