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

SeattleJS May 14, 2015

SeattleJS May 14, 2015

229ec15028bae7f1d4cdcfe91e2380b0?s=128

Henrik Joreteg

May 14, 2015
Tweet

Transcript

  1. Complexity Etc. @HenrikJoreteg

  2. THIS USED TO BE SIMPLE!

  3. 1. WRITE SOME HTML 2. LAY IT OUT WITH FRAMES

    OR TABLES 3. FTP IT TO A SERVER! 4. BAM!
  4. CONGRATULATIONS, YOU’RE A WEB DEVELOPER!

  5. THEN IT GOT HARDER

  6. WHO’S WRITTEN THEIR OWN BLOG SOFTWARE?

  7. OVER ENGINEERING A BLOG WAS A RITE OF PASSAGE

  8. 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
  9. CONGRATULATIONS, YOU’RE A WEB DEVELOPER!

  10. PHEW!!

  11. THEN WE GOT "SMART"

  12. USE A FRAMEWORK!!

  13. 1. RAILS 2. ALL THEM PHP FRAMEWORKS 3. DJANGO 4.

    ETC.
  14. OUR EXCESSIVLELY DYNAMIC BLOG… IS NOW BETTER ORGANIZED AND HAS

    MORE DEPENDENCIES
  15. CONGRATULATIONS, YOU’RE A WEB DEVELOPER!

  16. WHAT ABOUT TODAY?

  17. 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
  18. CONGRATULATIONS YOU MIGHT BE A "WEB DEVELOPER"

  19. WHAT DOES "WEB DEVELOPER" EVEN MEAN?

  20. WHAT DOES "WEB APP" EVEN MEAN?

  21. THE BROWSER ISN’T OUR RENDERER

  22. THE BROWSER IS OUR RUNTIME

  23. THE WEBVIEW IS OUR RUNTIME

  24. MORE LOGIC MOVING TO FRONT-END JS

  25. DEVS WITH DIFFERENT BACKGROUNDS CONVERGING ON JS

  26. BRINGING THEIR PATTERNS AND PREFERENCES

  27. 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
  28. SINGLE PAGE APPS

  29. HUH?

  30. SINGLE PAGE APPS

  31. "NATIVE"

  32. I’M A WEB DEVELOPER

  33. NATIVE WEB APP

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

  35. FUNDAMENTAL DISTINCTION…

  36. THE BROWSER IS YOUR RUNTIME

  37. SEND THE APP ITSELF TO THE BROWSER INSTEAD OF THE

    RESULT OF RUNNING IT
  38. <!doctype> <script src="app.1.3.7.js"></script>

  39. SHOULD WE EVEN BE DOING THIS?

  40. SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?

  41. None
  42. SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?

  43. {{ RAISE YOUR HAND }}

  44. YES!

  45. WHAT SERVICE ARE WE PROVIDING?

  46. CONTENT?

  47. CONTENT SHOULD JUST WORK™

  48. NO REASON TO COMPLICATE THINGS THAT CAN BE SIMPLE

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

  50. THERE ARE CASES WHERE CLIENTSIDE FUNCTIONALITY IS THE CORE VALUE

    PROVIDED BY SERVICE
  51. None
  52. None
  53. None
  54. None
  55. 1. RENDERING 2. NETWORKING 3. FILE READ/WRITE 4. STORAGE 5.

    WEB AUDIO APIS 6. WEBGL 7. VOICE/VIDEO HIGH PERFORMANCE
  56. BROWSERS ARE NOT DUMB DOCUMENT VIEWERS

  57. MOST CAPABLE UBIQUITOUS RUNTIMES ON THE PLANET

  58. I’M JUST GOING TO SAY IT:

  59. THERE ARE TWO TYPES OF APPLICATIONS ON THE WEB

  60. 1. NATIVE WEB APPS

  61. 2. SERVER-SIDE WEB APPS

  62. THEY ARE FUNDAMENTALLY DIFFERENT

  63. AND THAT’S O.K.

  64. ANYTHING WE CAN BUILD WITH WEB TECH I THINK WE

    SHOULD
  65. EVEN IF WE CAN’T SUPPORT OLDER BROWSERS

  66. THE WEB IS INFINITELY MORE OPEN THAN NATIVE PLATFORMS

  67. USER EXPECTATIONS HAVE EVOLVED

  68. THE WEB IS DOING PRETTY WELL ON DESKTOPS

  69. THE WEB IS LOSING ON MOBILE

  70. http://media.fb.com/2015/05/12/instantarticles/

  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. None
  83. WHERE’S THE DOWNSIDE?

  84. ACCESSIBILITY

  85. 98.6% SCREENREADERS HAPPILY RUN JS (in 2012) http://www.paulirish.com/2012/accessibility-and-developers/

  86. SEO

  87. https://medium.com/ben-and-dion/is-it-time-to- go-spa-only-did-google-bot-put-a-nail-in-the- server-rendered-coffin-d3d4128d1ec0 DION ALMAER VP Engineering Walmart Mobile

  88. PERFORMANCE

  89. LET’S LOOK A BIT CLOSER AT TWITTER

  90. WHAT IS TWITTER?

  91. IS IT A WEB APP?

  92. NO.

  93. IT’S A SERVICE

  94. APP != SERVICE

  95. TWITTER android app iOS app tweetbot twitter.com tweet deck ad

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

  97. BECAUSE I DIDN’T USE IT ANYWAY!

  98. I WAS USING AN iOS APP!

  99. THEIR WEB APP HAD ALREADY FAILED ME!

  100. LET’S THINK ABOUT THIS

  101. WHEN I FOLLOW A LINK TO A RANDOM TWEET ON

    MY PHONE…
  102. JUST LET ME READ IT!

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

  104. DON’T MAKE ME DOWNLOAD 2MB OF JS TO READ 140

    CHARACTERS OF TEXT!
  105. THIS IS THE PROBLEM THEY FIXED WITH NEW NEW TWITTER

  106. BUT…

  107. CATCHING UP WITH ALL THINGS TWITTER IS A FUNDAMENTALLY DIFFERENT

    USE CASE
  108. FAILING TO RECOGNIZE DISTINCTION MAKES US FLOUNDER

  109. A SERVICE CAN PROVIDE BOTH!

  110. TWITTER.COM & TWEETDECK.COM

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

  112. REAL OFFLINE SUPPORT

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

  114. THOSE THINGS ARE CHANGING

  115. 1. SERVICE WORKER

  116. PROGRAMMABLE CACHE LAYER CAN INTERCEPTS ALL NETWORK REQUESTS 1. SERVICE

    WORKER
  117. THIS IS HUGE!

  118. 2. INSTALLABLE WEB APPS

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

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

  121. "What about performance?"

  122. WHITE PAGE OF DEATH

  123. TIME TO FIRST PAINT

  124. A PRIMED CACHE LARGELY INVALIDATES THIS ARGUMENT

  125. <!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
  126. MOST OF THESE TYPES OF APPS REQUIRE YOU TO BE

    LOGGED IN
  127. PRE-FETCH OR EVEN PRE-RENDER THE ENTIRE APP ON PUBLIC PAGES

    OR LOGIN PAGE
  128. NATIVE WEB APPS CAN STILL HAVE SMALL JS PAYLOADS!

  129. ALL JS IN THE AMPERSAND.JS APP ON TODOMVC.COM COMBINED 28kb

    min + gzip
  130. SMALLER THAN JQUERY 2.0

  131. THE OTHER ASPECT OF PERFORMANCE…

  132. ONCE LOADED, PERFORMANCE IS WAY BETTER!

  133. IF I’M GOING TO LEAVE APP OPEN ON MY DESKTOP

    I CARE WAY LESS ABOUT LOAD TIME
  134. "What about dual rendered a.k.a. isomorphic apps?"

  135. ARGUABLY "PORTABLE JS" IS A BETTER WORD

  136. JUST A CLIENTSIDE APP WITH AN OPTIMIZED INITIAL RENDER

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

  138. OFTEN REQUIRES DRAMATICALLY MORE COMPLEX CODE

  139. THERE ARE SOME CASES WHERE IT MAKES SENSE

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

  141. HOWEVER…

  142. DOESN’T HAVE TO BE ALL OR NOTHING

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

  144. WE CAN DO THIS AS A FULLY STATIC SITE

  145. 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:
  146. WOAH!

  147. APPS USUALLY HAVE: 1. public/marketing pages 2. all the stuff

    behind the login
  148. WRITE "PUBLIC" PAGES AND APP LAYOUT HTML AS ISOMORPHIC COMPONENTS

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

  150. SLIP IN THE BUILT JS BEFORE: </body>

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

  152. Isomorphic Rendering™ It’s not quite

  153. LazyMorphic Rendering™ It’s more like

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

  155. THINK ABOUT WHAT WE GET

  156. pixels on the screen immediately

  157. TOTALLY CRAWLABLE (SEO)

  158. JS TAKES OVER ROUTING WHEN LOADED

  159. DEPLOYMENT AND OPS BECOME AS SIMPLE AS FTP

  160. WRITE 1 VERSION OF YOUR APP GET 90% OF BENEFIT

    FROM ISOMORPHIC RENDERING
  161. USERS WILL END UP WITH A PRIMED CACHE JUST BY

    VISITING YOUR MARKETING PAGES
  162. READY FOR: PHONEGAP/CORDOVA DESKTOP APP

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

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

    APPS
  165. TOTALLY <3 IT!

  166. FOR SO LONG THE TREND HAS BEEN TOWARD COMPLEXITY

  167. None
  168. WHAT’S THE NEXT STEP IN THE EVOLUTION OF THE "WEB

    APP"?
  169. GOING BACK TO SIMPLE

  170. GOING BACK TO THE STATIC WEB

  171. STATIC NATIVE WEB APPS

  172. POWERED BY SERVICES SOME WHICH WE BUILD MANY OF WHICH

    WE RENT
  173. surge.sh hood.ie firebase.com auth0.com divshot.com

  174. SIMPLE OPEN SOURCE EXAMPLE: HubTags.com

  175. {{ DEMO }}

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

  177. learn.humanjavascript.com 5-Hour Video Tutorial showing line by line how to

    build that app
  178. AMPERSAND.JS

  179. THE NAME "ampersand.js" IS A FILTHY LIE

  180. BECAUSE NO SUCH FILE EXISTS! <script src="ampersand.js"></script>

  181. WE JUST NAMED IT SOMETHING SO IT’S EASIER TO TALK

    ABOUT
  182. THERE’S NOTHING YOU CAN DROP INTO A SCRIPT TAG WITHOUT

    A BUILD STEP
  183. SEPARATE COMMON.JS MODULES

  184. INDIVIDUALLY INSTALLED VIA NPM

  185. BUILD WITH BROWSERIFY OR WEBPACK

  186. ampersand-state ampersand-model ampersand-collection ampersand-rest-collection ampersand-view ampersand-router

  187. ampersand (the CLI) ampersand-app ampersand-view-switcher ampersand-input-view ampersand-select-view ampersand-form-view etc.

  188. INDIVIDUAL GITHUB REPOS

  189. STRICT SEMVER

  190. todomvc.com

  191. FLEXIBILITY MODULARITY SO WHAT?!

  192. ONLY SEND CODE YOU USE

  193. AMPERSAND TODOMVC: ~28kb min+gzip

  194. MODULARITY LETS YOU REMODEL THE KITCHEN WITHOUT BURNING DOWN THE

    WHOLE BUILDING
  195. Angular 2.0

  196. MIX AND MATCH WHAT YOU WANT

  197. WhatsApp: ampersand-state w/ react

  198. FlipKart ampersand-* React

  199. Yahoo! ampersand-router

  200. BUT MODULARITY ISN’T THE ONLY FEATURE

  201. ONE EXAMPLE OF WHY WE FORKED

  202. SMARTER/STRICTER MODELS

  203. var model = new Backbone.Model({ name: 'henrik' }); model.on('change:name', function

    () { console.log('new changed'); }); model.set({name: 'bob'}); Backbone Models
  204. IF MODELS ARE OUR SOURCE OF TRUTH… WE WANT THEM

    TO BE MORE READABLE
  205. YOU HAVE TO DEFINE WHAT YOU STORE

  206. var Person = AmpersandState.extend({ props: { name:'string' } }); var

    model = new Model({name: 'henrik'}); model.on('change:name', someFunc); model.name = 'bob'; // still fires event model.name = 47; // throws TypeError
  207. SESSION STATE: RELATED, NOT PERSISTED

  208. var Person = AmpState.extend({ props: { name:'string' }, session: {

    active:'boolean' } }); var model = new Person({ name: 'henrik', active: true }); model.active; //=> true model.toJSON(); //=> {name: 'henrik'}
  209. GETTER/SETTER TRANFORMATIONS

  210. var Person = AmpState.extend({ props: { today: 'date' } });

    // unix timestamp coming in var henrik = new Person({today: '1418338921707'}); // getter returns Date Object henrik.today; //=> JS `Date` instance // timestamp when serializing JSON.stringify(henrik); //=> {today: 1418338921707}
  211. CACHED, OBSERVABLE DERIVED PROPERTIES

  212. var Person = AmpState.extend({ props: { name: 'string' }, derived:

    { nickName: { deps: ['name'], fn: function () { return this.name.slice(0, 3); } } } });
  213. var someone = new Person({name: 'henrik'}); someone.on('change:nickName', logChange); // computed

    only once and cached someone.nickName; //=> 'hen' // not triggered if result is same someone.name = 'henry'; // only if different someone.name = 'crazy'; // logs changed nick: 'cra'
  214. 1. derive from child models 2. derive from other derived

    3. useful for relationships between models 4. cannot set directly 5. resulting model code is more readable CACHED, EVENTED, DERIVED PROPERTIES
  215. READ MORE IN DOCS http://ampersandjs.com

  216. WEB + IRC CHATROOM: https://gitter.im/AmpersandJS/AmpersandJS https://irc.gitter.im/

  217. andyet.com

  218. HOW CAN WE BE SURE WE’RE BUILDING WITH THE RIGHT

    TOOLS?!
  219. WE CAN’T!

  220. WHAT DO WE KNOW?

  221. THINGS WILL CHANGE

  222. OPTIMIZE FOR MODULARITY

  223. OPTIMIZE FOR SIMPLICITY

  224. STATIC NATIVE WEB APPS

  225. BUILDING MICROSERVICES TO ENABLE THAT TYPE OF APP

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

  227. LET’S KEEP PUSHING FOR SIMPLICITY

  228. THANKS! @HenrikJoreteg, andyet.com