The Evolution of the "Web App" - FluentConf 2015

Transcript

1. Evolution of the "Web App"
   @HenrikJoreteg
   

   View Slide

2. @Hoarse_JS
   

   View Slide

3. THIS USED TO BE SIMPLE!
   

   View Slide

4. 1. WRITE SOME HTML
   2. LAY IT OUT WITH FRAMES OR TABLES
   3. FTP IT TO A SERVER!
   4. BAM!
   

   View Slide

5. CONGRATULATIONS,
   YOU’RE A WEB DEVELOPER!
   

   View Slide

6. THEN IT GOT HARDER
   

   View Slide

7. WHO’S WRITTEN THEIR
   OWN BLOG SOFTWARE?
   

   View Slide

8. OVER ENGINEERING A
   BLOG WAS A RITE OF PASSAGE
   

   View Slide

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
   

   View Slide

10. CONGRATULATIONS,
    YOU’RE A WEB DEVELOPER!
    

    View Slide

11. PHEW!!
    

    View Slide

12. THEN WE GOT "SMART"
    

    View Slide

13. USE A FRAMEWORK!!
    

    View Slide

14. 1. RAILS
    2. ALL THEM PHP FRAMEWORKS
    3. DJANGO
    4. ETC.
    

    View Slide

15. OUR EXCESSIVLELY DYNAMIC BLOG…
    IS NOW BETTER ORGANIZED
    AND HAS MORE DEPENDENCIES
    

    View Slide

16. CONGRATULATIONS,
    YOU’RE A WEB DEVELOPER!
    

    View Slide

17. WHAT ABOUT TODAY?
    

    View Slide

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
    

    View Slide

19. CONGRATULATIONS
    YOU MIGHT BE A
    "WEB DEVELOPER"
    

    View Slide

20. WHAT DOES
    "WEB DEVELOPER"
    EVEN MEAN?
    

    View Slide

21. WHAT DOES
    "WEB APP"
    EVEN MEAN?
    

    View Slide

22. THE BROWSER ISN’T
    OUR RENDERER
    

    View Slide

23. THE BROWSER IS
    OUR RUNTIME
    

    View Slide

24. THE WEBVIEW IS
    OUR RUNTIME
    

    View Slide

25. MORE LOGIC MOVING
    TO FRONT-END JS
    

    View Slide

26. DEVS WITH DIFFERENT
    BACKGROUNDS
    CONVERGING ON JS
    

    View Slide

27. BRINGING THEIR PATTERNS
    AND PREFERENCES
    

    View Slide

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
    

    View Slide

29. SINGLE PAGE APPS
    

    View Slide

30. HUH?
    

    View Slide

31. SINGLE PAGE APPS
    

    View Slide

32. "NATIVE"
    

    View Slide

33. I’M A WEB DEVELOPER
    

    View Slide

34. NATIVE WEB APP
    

    View Slide

35. 1. JAVASCRIPT
    2. HTML
    3. CSS
    4. BROWSER APIS
    

    View Slide

36. FUNDAMENTAL DISTINCTION…
    

    View Slide

37. THE BROWSER IS
    YOUR RUNTIME
    

    View Slide

38. SEND THE APP ITSELF
    TO THE BROWSER
    INSTEAD OF THE
    RESULT OF RUNNING IT
    

    View Slide

39. 
    
    

    View Slide

40. SHOULD WE EVEN BE DOING THIS?
    

    View Slide

41. SHOULD WE BUILD
    APPS THAT REQUIRE
    JAVASCRIPT?
    

    View Slide

42. View Slide

43. SHOULD WE BUILD
    APPS THAT REQUIRE
    JAVASCRIPT?
    

    View Slide

44. {{ RAISE YOUR HAND }}
    

    View Slide

45. YES!
    

    View Slide

46. WHAT SERVICE ARE WE PROVIDING?
    

    View Slide

47. CONTENT?
    

    View Slide

48. CONTENT SHOULD JUST WORK™
    

    View Slide

49. NO REASON TO COMPLICATE
    THINGS THAT CAN BE SIMPLE
    

    View Slide

50. BUT THE WEB IS
    NO LONGER
    JUST ABOUT
    LINKED CONTENT!
    

    View Slide

51. THERE ARE CASES
    WHERE CLIENTSIDE
    FUNCTIONALITY
    IS THE CORE VALUE
    PROVIDED BY SERVICE
    

    View Slide

52. View Slide

53. View Slide

54. View Slide

55. View Slide

56. 1. RENDERING
    2. NETWORKING
    3. FILE READ/WRITE
    4. STORAGE
    5. WEB AUDIO APIS
    6. WEBGL
    7. VOICE/VIDEO
    HIGH PERFORMANCE
    

    View Slide

57. BROWSERS ARE NOT
    DUMB DOCUMENT VIEWERS
    

    View Slide

58. MOST CAPABLE
    UBIQUITOUS
    RUNTIMES
    ON THE PLANET
    

    View Slide

59. I’M JUST GOING TO SAY IT:
    

    View Slide

60. THERE ARE TWO
    TYPES OF APPLICATIONS
    ON THE WEB
    

    View Slide

61. 1. NATIVE WEB APPS
    

    View Slide

62. 2. SERVER-SIDE WEB APPS
    

    View Slide

63. THEY ARE
    FUNDAMENTALLY
    DIFFERENT
    

    View Slide

64. AND THAT’S O.K.
    

    View Slide

65. ANYTHING
    WE CAN BUILD
    WITH WEB TECH
    I THINK WE SHOULD
    

    View Slide

66. EVEN IF WE CAN’T
    SUPPORT OLDER
    BROWSERS
    

    View Slide

67. THE WEB IS INFINITELY MORE
    OPEN
    THAN NATIVE PLATFORMS
    

    View Slide

68. USER EXPECTATIONS HAVE EVOLVED
    

    View Slide

69. THE WEB IS DOING PRETTY WELL
    ON DESKTOPS
    

    View Slide

70. THE WEB IS LOSING
    ON MOBILE
    

    View Slide

71. THE WEB IS LOSING
    ON EXPERIENCE
    

    View Slide

72. WE OFTEN PREFER NATIVE
    APPS TO THE WEB
    

    View Slide

73. QUALITY AND POLISH
    OF USER EXPERIENCE
    IS OFTEN MUCH BETTER
    

    View Slide

74. LET’S FIX THIS!
    

    View Slide

75. WE’RE TOO FOCUSED
    ON THE PAST INSTEAD OF
    COMPETING ON EXPERIENCE
    

    View Slide

76. SAYING THERE’S A DISTINCTION
    MAKES SOME PEOPLE MAD
    

    View Slide

77. "Everything should be an enhancement!"
    

    View Slide

78. WE’RE ON THE
    SAME TEAM!
    

    View Slide

79. WE WANT THE
    OPEN WEB
    TO WIN!
    

    View Slide

80. HOW COULD WE EVEN
    BUILD A PROGRESSIVELY
    ENHANCED VERSION
    OF TALKY?
    

    View Slide

81. SHOULD WE NOT HAVE
    BUILT IT?
    

    View Slide

82. WHERE’S THE DOWNSIDE?
    

    View Slide

83. LET’S LOOK A BIT CLOSER AT TWITTER
    

    View Slide

84. WHAT IS TWITTER?
    

    View Slide

85. IS IT A WEB APP?
    

    View Slide

86. NO.
    

    View Slide

87. IT’S A SERVICE
    

    View Slide

88. APP != SERVICE
    

    View Slide

89. TWITTER
    android app
    iOS app
    tweetbot
    twitter.com
    tweet deck
    ad dashboard
    

    View Slide

90. I DIDN’T REALLY
    CARE HOW THEY
    BUILT THEIR WEBAPP
    

    View Slide

91. BECAUSE I DIDN’T
    USE IT ANYWAY!
    

    View Slide

92. I WAS USING AN iOS APP!
    

    View Slide

93. THEIR WEB APP HAD
    ALREADY FAILED ME!
    

    View Slide

94. LET’S THINK ABOUT THIS
    

    View Slide

95. WHEN I FOLLOW
    A LINK TO A
    RANDOM TWEET
    ON MY PHONE…
    

    View Slide

96. JUST LET ME READ IT!
    

    View Slide

97. plain text
    I DON’T MIND IF IT’S
    

    View Slide

98. DON’T MAKE ME
    DOWNLOAD
    2MB OF JS
    TO READ
    140 CHARACTERS
    OF TEXT!
    

    View Slide

99. THIS IS THE PROBLEM
    THEY FIXED WITH
    NEW NEW TWITTER
    

    View Slide

100. BUT…
     

     View Slide

101. CATCHING UP WITH
     ALL THINGS TWITTER
     IS A FUNDAMENTALLY
     DIFFERENT USE CASE
     

     View Slide

102. FAILING TO RECOGNIZE
     DISTINCTION MAKES US
     FLOUNDER
     

     View Slide

103. A SERVICE CAN
     PROVIDE BOTH!
     

     View Slide

104. TWITTER.COM
     &
     TWEETDECK.COM
     

     View Slide

105. THERE’S STILL SOME GAPS
     BETWEEN WEB AND NATIVE
     

     View Slide

106. REAL OFFLINE SUPPORT
     

     View Slide

107. PLATFORMS THAT TREAT
     NATIVE WEB APPS AS
     FIRST CLASS
     CITIZENS
     

     View Slide

108. THOSE THINGS
     ARE CHANGING
     

     View Slide

109. 1. SERVICE WORKER
     

     View Slide

110. PROGRAMMABLE
     CACHE LAYER
     CAN INTERCEPTS ALL
     NETWORK REQUESTS
     1. SERVICE WORKER
     

     View Slide

111. THIS IS
     HUGE!
     

     View Slide

112. 2. INSTALLABLE WEB APPS
     

     View Slide

113. CHROME M39+
     FIREFOX
     https://developer.chrome.com/multidevice/android/installtohomescreen
     https://w3c.github.io/manifest/
     JSON-BASED WEB MANIFEST
     

     View Slide

114. 1. SIGNAL INTENT
     2.UNINSTALL
     3.DEEPER DEVICE APIS
     

     View Slide

115. "What about performance?"
     

     View Slide

116. WHITE PAGE
     OF DEATH
     

     View Slide

117. TIME TO FIRST PAINT
     

     View Slide

118. A PRIMED CACHE
     LARGELY INVALIDATES
     THIS ARGUMENT
     

     View Slide

119. 
     
     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
     

     View Slide

120. MOST OF THESE
     TYPES OF APPS
     REQUIRE YOU
     TO BE LOGGED IN
     

     View Slide

121. PRE-FETCH APP
     ON PUBLIC PAGES
     OR LOGIN PAGE
     

     View Slide

122. NATIVE WEB APPS CAN
     STILL HAVE SMALL
     JS PAYLOADS!
     

     View Slide

123. ALL JS IN THE
     AMPERSAND.JS APP
     ON TODOMVC.COM
     COMBINED
     28kb min + gzip
     

     View Slide

124. SMALLER THAN JQUERY 2.0
     

     View Slide

125. THE OTHER ASPECT
     OF PERFORMANCE…
     

     View Slide

126. ONCE LOADED,
     PERFORMANCE
     IS WAY BETTER!
     

     View Slide

127. IF I’M GOING TO
     LEAVE APP OPEN
     ON MY DESKTOP
     I CARE WAY LESS
     ABOUT LOAD TIME
     

     View Slide

128. "What about dual rendered
     a.k.a. isomorphic apps?"
     

     View Slide

129. JUST A CLIENTSIDE APP
     WITH AN OPTIMIZED
     INITIAL RENDER
     

     View Slide

130. GOING FULL-ISOMORPHIC
     RENDERING, WITH USER DATA
     AND ALL…
     

     View Slide

131. OFTEN REQUIRES
     DRAMATICALLY
     MORE COMPLEX CODE
     

     View Slide

132. THERE ARE SOME CASES
     WHERE IT MAKES SENSE
     

     View Slide

133. WITH STATE OF
     TOOLING TODAY
     OFTEN NOT WORTH
     THE COMPLEXITY
     

     View Slide

134. HOWEVER…
     

     View Slide

135. DOESN’T HAVE TO BE
     ALL OR NOTHING
     

     View Slide

136. WE CAN PRE-RENDER EVERYTHING
     THAT’S NOT USER-SPECIFIC DATA
     

     View Slide

137. WE CAN DO THIS AS
     A FULLY STATIC SITE
     

     View Slide

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:
     

     View Slide

139. WOAH!
     

     View Slide

140. APPS USUALLY HAVE:
     1. public/marketing pages
     2. all the stuff behind the login
     

     View Slide

141. WRITE "PUBLIC" PAGES
     AND APP LAYOUT HTML
     AS ISOMORPHIC
     COMPONENTS
     

     View Slide

142. PRE-RENDER THEM
     TO STATIC PAGES
     AT BUILD TIME!
     

     View Slide

143. SLIP IN THE BUILT JS BEFORE:
     

     View Slide

144. index.html: public home page
     200.html: application layout
     

     View Slide

145. COULD POTENTIALLY EVEN DO THIS
     FOR DYNAMIC/PUBLIC DATA
     

     View Slide

146. THINK ABOUT WHAT WE GET
     

     View Slide

147. pixels on the screen immediately
     

     View Slide

148. TOTALLY CRAWLABLE (SEO)
     

     View Slide

149. JS TAKES OVER ROUTING
     WHEN LOADED
     

     View Slide

150. DEPLOYMENT AND OPS
     BECOME AS SIMPLE AS FTP
     

     View Slide

151. WRITE 1 VERSION OF YOUR APP
     GET 90% OF BENEFIT FROM
     ISOMORPHIC RENDERING
     

     View Slide

152. USERS WILL END UP WITH A PRIMED
     CACHE JUST BY VISITING YOUR
     MARKETING PAGES
     

     View Slide

153. READY FOR:
     PHONEGAP/CORDOVA
     DESKTOP APP
     

     View Slide

154. NOW WE HAVE AN APP
     WITH A SINGULAR CONCERN:
     PRESENTATION
     

     View Slide

155. I’VE STARTING BUILDING
     ALL MY APPS AS STATIC
     NATIVE WEB APPS
     

     View Slide

156. TOTALLY <3 IT!
     

     View Slide

157. FOR SO LONG THE TREND
     HAS BEEN TOWARD COMPLEXITY
     

     View Slide

158. View Slide

159. WHAT’S THE NEXT STEP
     IN THE EVOLUTION
     OF THE "WEB APP"?
     

     View Slide

160. GOING BACK TO
     SIMPLE
     

     View Slide

161. GOING BACK TO
     THE STATIC WEB
     

     View Slide

162. STATIC NATIVE WEB APPS
     

     View Slide

163. POWERED BY SERVICES
     SOME WHICH WE BUILD
     MANY OF WHICH WE RENT
     

     View Slide

164. surge.sh
     hood.ie
     firebase.com
     auth0.com
     divshot.com
     

     View Slide

165. SIMPLE OPEN SOURCE EXAMPLE:
     HubTags.com
     

     View Slide

166. •React
     •Ampersand.js
     •Webpack (hjs-webpack)
     •GitHub API
     •Surge.sh
     

     View Slide

167. andyet.com
     

     View Slide

168. HOW CAN WE BE SURE
     WE’RE BUILDING WITH
     THE RIGHT TOOLS?!
     

     View Slide

169. WE CAN’T!
     

     View Slide

170. WHAT DO WE KNOW?
     

     View Slide

171. THINGS WILL
     CHANGE
     

     View Slide

172. BUILD MODULAR SYSTEMS
     THAT STRIVE TO BE AS
     SIMPLE AS THEY CAN BE
     

     View Slide

173. OFFLOADING PRESENTATION
     STATIC NATIVE WEB APPS
     

     View Slide

174. BUILDING MICROSERVICES
     TO ENABLE THAT TYPE OF APP
     

     View Slide

175. OPTIMIZE FOR CHANGE.
     IT IS THE ONLY CONSTANT.
     

     View Slide

176. LET’S KEEP PUSHING FOR SIMPLICITY
     

     View Slide

177. LET’S BUILD FOR THE FUTURE
     OF THE WEB, NOT ITS PAST
     

     View Slide

178. THANKS!
     @HenrikJoreteg, andyet.com
     

     View Slide