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?

42. None

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
52. None
53. None
54. None
55. None

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

158. None

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