Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Evolution of the "Web App" - FluentConf 2015

The Evolution of the "Web App" - FluentConf 2015

Henrik Joreteg

April 23, 2015
Tweet

More Decks by Henrik Joreteg

Other Decks in Technology

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