The Evolution of the "Web App" - FluentConf 2015

The Evolution of the "Web App" - FluentConf 2015

229ec15028bae7f1d4cdcfe91e2380b0?s=128

Henrik Joreteg

April 23, 2015
Tweet

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