1. Web development used to be simple but has become increasingly complex over time as new technologies and frameworks have emerged. 2. The document argues that there is a distinction between native web apps that run entirely in the browser using JavaScript and server-side web apps, and that both have valid uses. 3. It advocates for building single-page apps as native web apps using modern browser capabilities and deploying them as static sites for performance and simplicity while relying on external services for backend functionality.

1. Optimizing For Change
@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. A WHOLE LOT
HAS CHANGED

40. SHOULD WE EVEN BE DOING THIS?

41. SHOULD WE BUILD
APPS THAT REQUIRE
JAVASCRIPT?

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

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. http://media.fb.com/2015/05/12/instantarticles/

72. THE WEB IS LOSING
ON EXPERIENCE

73. WE OFTEN PREFER NATIVE
APPS TO THE WEB

74. QUALITY AND POLISH
OF USER EXPERIENCE
IS OFTEN MUCH BETTER

75. LET’S FIX THIS!

76. WE’RE TOO FOCUSED
ON THE PAST INSTEAD OF
COMPETING ON EXPERIENCE

77. SAYING THERE’S A DISTINCTION
MAKES SOME PEOPLE MAD

78. "Everything should be an enhancement!"

79. WE’RE ON THE
SAME TEAM!

80. WE WANT THE
OPEN WEB
TO WIN!

81. HOW COULD WE EVEN
BUILD A PROGRESSIVELY
ENHANCED VERSION
OF TALKY?

82. 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 ALMAERVP 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. WE’RE USING PURE
WEB TECHNOLOGIES

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

166. TOTALLY <3 IT!

167. FOR SO LONG THE TREND
HAS BEEN TOWARD COMPLEXITY

169. MY
FUTURE INSIGHT
REGARDING "WEB APPS"?

170. GOING BACK TO
SIMPLE

171. GOING BACK TO
THE STATIC WEB

172. STATIC NATIVE WEB APPS

173. POWERED BY SERVICES
SOME WHICH WE BUILD
MANY OF WHICH WE RENT

174. surge.sh
hood.ie
firebase.com
auth0.com
divshot.com

175. SIMPLE OPEN SOURCE EXAMPLE:
HubTags.com

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. “So what about all these clientside
frameworks anyway?”

179. andyet.com

180. ~30 DEVS
LOTS OF JS
LOTS OF APPS

181. FLEXIBILITY IS VITAL

182. TOO RISKY TO GO “ALL-IN”

183. FLEXIBILITY
MODULARITY
SO WHAT?!

184. FRONTENDS ARE
NOT AS DISPOSABLE
AS THEY ONCE WERE

185. MODULARITY
LETS YOU REMODEL
THE KITCHEN WITHOUT
BURNING DOWN THE
WHOLE BUILDING

186. Angular 2.0

187. AMPERSAND.JS

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

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

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

191. THERE’S NOTHING
YOU CAN DROP
INTO A SCRIPT TAG
WITHOUT A BUILD STEP

192. SEPARATE COMMON.JS MODULES

193. INDIVIDUALLY
INSTALLED VIA NPM

194. BUILD WITH
BROWSERIFY
OR WEBPACK

195. THERE IS NO “CORE”

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

197. INDIVIDUAL GITHUB REPOS

198. todomvc.com

199. ONLY SEND
CODE YOU USE

200. MIX AND MATCH
WHAT YOU WANT

201. WhatsApp:
ampersand-state w/ react

202. FlipKart
ampersand-*
React

203. Yahoo!
ampersand-router

204. andyet.com

205. HOW CAN WE BE SURE
WE’RE BUILDING WITH
THE RIGHT TOOLS?!

206. WE CAN’T!

207. WHAT DO WE KNOW?

208. THINGS WILL
CHANGE

209. OPTIMIZE FOR MODULARITY

210. OPTIMIZE FOR SIMPLICITY

211. SEPARATING CONCERNS

212. …

213. COMPLETELY STATIC FRONT END

214. BUILDING MICROSERVICES
TO ENABLE THAT TYPE OF APP

215. LET’S KEEP PUSHING FOR SIMPLICITY

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

217. THANKS!@HenrikJoreteg, andyet.com