A Single Page Story – http://ffconf.org/

Single page apps have become a legitimate part of the web, but what role should they play? Where do they shine? Where do they fail? How should we think about them and how can we evaluate tools for building them? We will opine on the tradeoffs of abstractions and frameworks and share &yet's impetus for creating Ampersand.js.

Transcript

1. A Single Page Story @HenrikJoreteg
2. WHY AM I HERE?
3. http://blog.andyet.com/2014/08/13/opinionated-rundown-of-js-frameworks
4. "Hey! I read your book, Human JavaScript and your recent post about frameworks" - Remy
5. "holy s*** Remy reads my stuff?!"
6. "Come talk at my conference!"
7. *hyperventilates*
8. *dies* x x
9. DEFIBRILLATOR, CPR, etc…
10. "So should I turn that frameworks post into a talk? (I’ve got this)"
11. "No. Talk about clientside apps, in general. Like… should we even do them? What is their place on the web?"
12. LET ME TRANSLATE:
13. "No. Please publicly open Pandora’s box on my stage."
14. "… and take the inevitable beatings that follow."
15. *shudders in fear*
16. *dies* (again) x x
17. *dies* (again) x x
18. OK. Let’s do this.
19. "Like it or not we live in interesting times."
20. "They are times of danger and uncertainty"
21. - Robert F. Kennedy from a prophetic speech in 1966 about clientside javascript today
22. SINGLE PAGE APP
23. HUH?
24. JAVASCRIPT APPS
25. FRONT-END APPS
26. THICK CLIENTS
27. RIAs?
28. NATIVE WEB APP
29. FUNDAMENTAL DISTINCTION…
30. THE BROWSER IS YOUR RUNTIME
31. SEND THE APP ITSELF TO THE BROWSER INSTEAD OF THE RESULT OF RUNNING IT
32. <!doctype> <script src="app.1.3.7.js"></script>
33. IS IT EVEN A GOOD IDEA?
34. SHOULD WE EVEN BE DOING THIS?
36. "They are times of danger and uncertainty"
37. SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?
38. {{ RAISE YOUR HAND }}
39. YES!
40. WHAT SERVICE ARE WE PROVIDING?
41. CONTENT?
42. CONTENT SHOULD JUST WORK™
43. NO REASON TO COMPLICATE THINGS THAT CAN BE SIMPLE
44. BUT THE WEB IS NO LONGER JUST ABOUT LINKED CONTENT!
45. "They are times of danger and uncertainty"
46. THERE ARE CASES WHERE CLIENTSIDE FUNCTIONALITY IS THE CORE VALUE PROVIDED BY SERVICE
52. 1. RENDERING 2. NETWORKING 3. FILE READ/WRITE 4. STORAGE 5. WEB AUDIO APIS 6. WEBGL 7. VOICE/VIDEO HIGH PERFORMANCE
53. BROWSERS ARE NOT DUMB DOCUMENT VIEWERS
54. MOST CAPABLE UBIQUITOUS RUNTIMES ON THE PLANET
55. "we live in interesting times."
56. I’M JUST GOING TO SAY IT:
57. THERE ARE TWO TYPES OF APPLICATIONS ON THE WEB
58. 1. NATIVE WEB APPS
59. 2. SERVER-SIDE WEB APPS
60. THEY ARE FUNDAMENTALLY DIFFERENT
61. AND THAT’S O.K.
62. ANYTHING WE CAN BUILD WITH WEB TECH I THINK WE SHOULD
63. EVEN IF WE CAN’T SUPPORT OLDER BROWSERS
64. THE WEB IS INFINITELY MORE OPEN AND ACCESSIBLE THAN NATIVE PLATFORMS
65. USER EXPECTATIONS HAVE EVOLVED
66. THE WEB IS DOING PRETTY WELL ON DESKTOPS
67. THE WEB IS LOSING ON MOBILE
68. THE WEB IS LOSING ON EXPERIENCE
69. WE OFTEN PREFER NATIVE APPS TO THE WEB
70. QUALITY AND POLISH OF USER EXPERIENCE IS OFTEN MUCH BETTER
71. LET’S FIX THIS!
72. WE’RE TOO FOCUSED ON THE PAST INSTEAD OF COMPETING ON EXPERIENCE
73. SAYING THERE’S A DISTINCTION MAKES SOME PEOPLE MAD
74. "Everything should be an enhancement!"
75. WE’RE ON THE SAME TEAM!
76. WE WANT THE OPEN WEB TO WIN!
77. HOW COULD WE EVEN BUILD A PROGRESSIVELY ENHANCED VERSION OF TALKY.IO?
78. SHOULD WE NOT HAVE BUILT IT?
79. WHERE’S THE DOWNSIDE?
80. LET’S LOOK A BIT CLOSER AT TWITTER
81. WHAT IS TWITTER?
82. IS IT A WEB APP?
83. NO.
84. IT’S A SERVICE
85. APP != SERVICE
86. TWITTER android app iOS app tweetbot twitter.com tweet deck ad dashboard
87. I DIDN’T REALLY CARE HOW THEY BUILT THEIR WEBAPP
88. BECAUSE I DIDN’T USE IT ANYWAY!
89. I WAS USING AN iOS APP!
90. THEIR WEB APP HAD ALREADY FAILED ME!
91. LET’S THINK ABOUT THIS
92. WHEN I FOLLOW A LINK TO A RANDOM TWEET ON MY PHONE…
93. JUST LET ME READ IT!
94. plain text I DON’T MIND IF IT’S
95. DON’T MAKE ME DOWNLOAD 2MB OF JS TO READ 140 CHARACTERS OF TEXT!
96. THIS IS THE PROBLEM THEY FIXED WITH NEW NEW TWITTER
97. BUT…
98. CATCHING UP WITH ALL THINGS TWITTER IS A FUNDAMENTALLY DIFFERENT USE CASE
99. FAILING TO RECOGNIZE DISTINCTION MAKES US FLOUNDER
100. A SERVICE CAN PROVIDE BOTH!
101. TWITTER.COM & TWEETDECK.COM
102. THERE’S STILL SOME GAPS BETWEEN WEB AND NATIVE
103. REAL OFFLINE SUPPORT
104. PLATFORMS THAT TREAT NATIVE WEB APPS AS FIRST CLASS CITIZENS
105. THOSE THINGS ARE CHANGING
106. 1. SERVICE WORKER
107. PROGRAMMABLE CACHE LAYER CAN INTERCEPTS ALL NETWORK REQUESTS 1. SERVICE WORKER
108. THIS IS HUGE!
109. 2. INSTALLABLE WEB APPS
110. CHROME M39+ FIREFOX https://developer.chrome.com/multidevice/android/installtohomescreen https://w3c.github.io/manifest/ JSON-BASED WEB MANIFEST
111. ANDROID 5.0 AUTOUPDATING WEBVIEW
112. "What about performance?"
113. WHITE PAGE OF DEATH
114. TIME TO FIRST PAINT
115. A PRIMED CACHE LARGELY INVALIDATES THIS ARGUMENT
116. <!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
117. MOST OF THESE TYPES OF APPS REQUIRE YOU TO BE LOGGED IN
118. PRE-FETCH APP ON LOGIN PAGE
119. NATIVE WEB APPS CAN STILL HAVE SMALL JS PAYLOADS!
120. ALL JS IN THE AMPERSAND.JS APP ON TODOMVC.COM COMBINED 28kb min + gzip
121. SMALLER THAN JQUERY 2.0
122. THE OTHER ASPECT OF PERFORMANCE…
123. ONCE LOADED, PERFORMANCE IS WAY BETTER!
124. IF I’M GOING TO LEAVE APP OPEN ON MY DESKTOP I CARE WAY LESS ABOUT LOAD TIME
125. "What about dual rendered a.k.a. isomorphic apps?"
126. JUST A CLIENTSIDE APP WITH AN OPTIMIZED INITIAL RENDER
127. OFTEN REQUIRES DRAMATICALLY MORE COMPLEX CODE
128. CLIENT TIGHTLY COUPLED TO SERVER
129. THERE ARE SOME CASES WHERE IT MAKES SENSE
130. WITH STATE OF TOOLING TODAY OFTEN NOT WORTH THE COMPLEXITY
131. SEND RENDERED LAYOUT HTML + STYLES
132. "What about all these clientside frameworks?"
133. FOR A FEW MORE SPECIFICS READ MY POST blog.andyet.com/2014/08/13/opinionated-rundown-of-js-frameworks
134. "In a rapidly evolving web, how can we be sure we’re picking the right tools?"
135. WE CAN’T!
136. "They are times of danger and uncertainty"
137. WHAT DO WE KNOW?
138. THINGS WILL CHANGE
139. SO HOW CAN WE CONFIDENTLY BUILD ANYTHING?
140. OPTIMIZE FOR CHANGE. IT IS THE ONLY CONSTANT.
141. HOW?!
142. LOSE YOUR RELIGION
143. DON’T INVEST TOO HEAVILY IN A SINGLE FRAMEWORK
144. FIGHT COMPLEXITY
146. CLIENTSIDE WEB APPS ARE COMPLEX SYSTEMS
147. HOW DO YOU BUILD COMPLEX SYSTEMS?
148. YOU DON’T
149. YOU ISOLATE AND SOLVE THE SMALLER PROBLEMS
150. THEN BUILD IT LIKE LEGOS: BRICK BY BRICK
151. MODULARITY IN A WORD:
152. IT’S HARDER!
153. "I didn't have the time to write you a short letter, so I wrote you a long letter instead." - Mark Twain
154. YOU HAVE TO DISTILL PROBLEMS INTO DISCREET COMPONENTS
155. YOU HAVE TO VALIDATE THOSE PIECES WORK AS EXPECTED
156. MODULES ARE A MACHINE SHOP NOT A HAMMER AND NAILS
157. YOU CAN PRODUCE AMAZING THINGS! BUT IT REQUIRES MORE OF THE OPERATOR
158. WHAT DO YOU GAIN?
159. MODULARITY LETS YOU REMODEL THE KITCHEN WITHOUT BURNING DOWN THE WHOLE BUILDING
160. Angular 2.0
161. andyet.com
162. ~30 DEVELOPERS GOBS OF JS APPS REALTIME APPS
163. AMPERSAND.JS
164. THE NAME "ampersand.js" IS A FILTHY LIE
165. BECAUSE NO SUCH FILE EXISTS! <script src="ampersand.js"></script>
166. THERE’S NOTHING YOU CAN DROP INTO A SCRIPT TAG WITHOUT A BUILD STEP
167. ampersand-state ampersand-model ampersand-collection ampersand-rest-collection ampersand-view ampersand-router
168. ampersand (the CLI) ampersand-app ampersand-view-switcher ampersand-input-view ampersand-select-view ampersand-form-view etc.
169. INDIVIDUAL GITHUB REPOS
170. ALL COMMON.JS MODULES
171. INSTALLED VIA NPM
172. BUILD WITH BROWSERIFY OR WEBPACK
173. todomvc.com
174. AMPERSAND + REACT
175. SOFTWARE IS A LONG-TERM GAME
176. "I could build that in a weekend!" WE ALL THINK:
177. "Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance." - Kurt Vonnegut
178. IF YOUR APP IS SUCCESSFUL IT WILL OUTLIVE THE ATTENTION SPAN OF ITS CREATORS
179. OPTIMIZE FOR CHANGE. IT IS THE ONLY CONSTANT.
180. "Like it or not we live in interesting times. They are times of danger and uncertainty;" But they are also more open to the creative energy of people than any other time in history."
181. "Like it or not we live in interesting times. They are times of danger and uncertainty;" But they are also more open to the creative energy of people than any other time in history."
182. LET’S BUILD FOR THE FUTURE OF THE WEB, NOT ITS PAST.
183. THANKS! @HenrikJoreteg, andyet.com