SeattleJS May 14, 2015

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?
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
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?
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
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