Page 1
Optimizing For Change@HenrikJoreteg
Page 2
THIS USED TO BE SIMPLE!
Page 3
1. WRITE SOME HTML 2. LAY IT OUT WITH FRAMES OR TABLES 3. FTP IT TO A SERVER! 4. BAM!
Page 4
CONGRATULATIONS, YOU’RE A WEB DEVELOPER!
Page 5
THEN IT GOT HARDER
Page 6
WHO’S WRITTEN THEIR OWN BLOG SOFTWARE?
Page 7
OVER ENGINEERING A BLOG WAS A RITE OF PASSAGE
Page 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
Page 9
CONGRATULATIONS, YOU’RE A WEB DEVELOPER!
Page 11
THEN WE GOT "SMART"
Page 12
USE A FRAMEWORK!!
Page 13
1. RAILS 2. ALL THEM PHP FRAMEWORKS 3. DJANGO 4. ETC.
Page 14
OUR EXCESSIVLELY DYNAMIC BLOG… IS NOW BETTER ORGANIZED
AND HAS MORE DEPENDENCIES
Page 15
CONGRATULATIONS, YOU’RE A WEB DEVELOPER!
Page 16
WHAT ABOUT TODAY?
Page 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
Page 18
CONGRATULATIONS YOU MIGHT BE A
"WEB DEVELOPER"
Page 19
WHAT DOES "WEB DEVELOPER"
EVEN MEAN?
Page 20
WHAT DOES "WEB APP" EVEN MEAN?
Page 21
THE BROWSER ISN’T OUR RENDERER
Page 22
THE BROWSER IS OUR RUNTIME
Page 23
THE WEBVIEW IS OUR RUNTIME
Page 24
MORE LOGIC MOVING TO FRONT-END JS
Page 25
DEVS WITH DIFFERENT BACKGROUNDS
CONVERGING ON JS
Page 26
BRINGING THEIR PATTERNS AND PREFERENCES
Page 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
Page 32
I’M A WEB DEVELOPER
Page 34
1. JAVASCRIPT 2. HTML 3. CSS 4. BROWSER APIS
Page 35
FUNDAMENTAL DISTINCTION…
Page 36
THE BROWSER IS YOUR RUNTIME
Page 37
SEND THE APP ITSELF TO THE BROWSER INSTEAD OF THE RESULT OF RUNNING IT
Page 38
<!doctype><script src="app.1.3.7.js"></script>
Page 39
A WHOLE LOT HAS CHANGED
Page 40
SHOULD WE EVEN BE DOING THIS?
Page 41
SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?
Page 43
SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?
Page 44
{{ RAISE YOUR HAND }}
Page 46
WHAT SERVICE ARE WE PROVIDING?
Page 48
CONTENT SHOULD JUST WORK™
Page 49
NO REASON TO COMPLICATE THINGS THAT CAN BE SIMPLE
Page 50
BUT THE WEB IS NO LONGER JUST ABOUT LINKED CONTENT!
Page 51
THERE ARE CASES WHERE CLIENTSIDE FUNCTIONALITY IS THE CORE VALUE PROVIDED BY SERVICE
Page 56
1. RENDERING 2. NETWORKING 3. FILE READ/WRITE 4. STORAGE 5. WEB AUDIO APIS 6. WEBGL 7. VOICE/VIDEO
HIGH PERFORMANCE
Page 57
BROWSERS ARE NOT DUMB DOCUMENT VIEWERS
Page 58
MOST CAPABLE UBIQUITOUS RUNTIMES ON THE PLANET
Page 59
I’M JUST GOING TO SAY IT:
Page 60
THERE ARE TWO TYPES OF APPLICATIONS
ON THE WEB
Page 61
1. NATIVE WEB APPS
Page 62
2. SERVER-SIDE WEB APPS
Page 63
THEY ARE FUNDAMENTALLY
DIFFERENT
Page 65
ANYTHING WE CAN BUILD
WITH WEB TECH I THINK WE SHOULD
Page 66
EVEN IF WE CAN’T SUPPORT OLDER
BROWSERS
Page 67
THE WEB IS INFINITELY MORE OPEN
THAN NATIVE PLATFORMS
Page 68
USER EXPECTATIONS HAVE EVOLVED
Page 69
THE WEB IS DOING PRETTY WELL ON DESKTOPS
Page 70
THE WEB IS LOSING ON MOBILE
Page 71
http://media.fb.com/2015/05/12/instantarticles/
Page 72
THE WEB IS LOSING ON EXPERIENCE
Page 73
WE OFTEN PREFER NATIVE APPS TO THE WEB
Page 74
QUALITY AND POLISH OF USER EXPERIENCE IS OFTEN MUCH BETTER
Page 76
WE’RE TOO FOCUSED ON THE PAST INSTEAD OF
COMPETING ON EXPERIENCE
Page 77
SAYING THERE’S A DISTINCTION MAKES SOME PEOPLE MAD
Page 78
"Everything should be an enhancement!"
Page 79
WE’RE ON THE SAME TEAM!
Page 80
WE WANT THE OPEN WEB
TO WIN!
Page 81
HOW COULD WE EVEN BUILD A PROGRESSIVELY
ENHANCED VERSION OF TALKY?
Page 82
SHOULD WE NOT HAVE BUILT IT?
Page 83
WHERE’S THE DOWNSIDE?
Page 85
98.6% SCREENREADERS HAPPILY RUN JS
(in 2012)http://www.paulirish.com/2012/accessibility-and-developers/
Page 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
Page 89
LET’S LOOK A BIT CLOSER AT TWITTER
Page 95
TWITTER
android app iOS app
tweetbottwitter.com
tweet deck
ad dashboard
Page 96
I DIDN’T REALLY CARE HOW THEY
BUILT THEIR WEBAPP
Page 97
BECAUSE I DIDN’T USE IT ANYWAY!
Page 98
I WAS USING AN iOS APP!
Page 99
THEIR WEB APP HAD ALREADY FAILED ME!
Page 100
LET’S THINK ABOUT THIS
Page 101
WHEN I FOLLOW A LINK TO A
RANDOM TWEET ON MY PHONE…
Page 102
JUST LET ME READ IT!
Page 103
plain textI DON’T MIND IF IT’S
Page 104
DON’T MAKE ME DOWNLOAD 2MB OF JS TO READ
140 CHARACTERS OF TEXT!
Page 105
THIS IS THE PROBLEM THEY FIXED WITH
NEW NEW TWITTER
Page 107
CATCHING UP WITH ALL THINGS TWITTER IS A FUNDAMENTALLY DIFFERENT USE CASE
Page 108
FAILING TO RECOGNIZE DISTINCTION MAKES US
FLOUNDER
Page 109
A SERVICE CAN PROVIDE BOTH!
Page 110
TWITTER.COM &
TWEETDECK.COM
Page 111
THERE’S STILL SOME GAPS BETWEEN WEB AND NATIVE
Page 112
REAL OFFLINE SUPPORT
Page 113
PLATFORMS THAT TREAT NATIVE WEB APPS AS
FIRST CLASS CITIZENS
Page 114
THOSE THINGS ARE CHANGING
Page 115
1. SERVICE WORKER
Page 116
PROGRAMMABLE CACHE LAYER
CAN INTERCEPTS ALL NETWORK REQUESTS
1. SERVICE WORKER
Page 118
2. INSTALLABLE WEB APPS
Page 119
CHROME M39+ FIREFOX
https://developer.chrome.com/multidevice/android/installtohomescreen
https://w3c.github.io/manifest/
JSON-BASED WEB MANIFEST
Page 120
1. SIGNAL INTENT 2. UNINSTALL 3. DEEPER DEVICE APIS
Page 121
"What about performance?"
Page 122
WHITE PAGE OF DEATH
Page 123
TIME TO FIRST PAINT
Page 124
A PRIMED CACHE LARGELY INVALIDATES
THIS ARGUMENT
Page 125
<!doctype><script src="app-1.2.7.js"></script>
1. GIVE IT A UNIQUE NAME
HTTP/1.1 200 OKCache-Control: max-age=REALLY BIG NUMBER!Content-Encoding: gzip
2. CACHE IT FOREVER
Page 126
MOST OF THESE TYPES OF APPS REQUIRE YOU
TO BE LOGGED IN
Page 127
PRE-FETCH OR EVEN PRE-RENDER
THE ENTIRE APP ON PUBLIC PAGES OR LOGIN PAGE
Page 128
NATIVE WEB APPS CAN STILL HAVE SMALL
JS PAYLOADS!
Page 129
ALL JS IN THE AMPERSAND.JS APP ON TODOMVC.COM
COMBINED 28kb min + gzip
Page 130
SMALLER THAN JQUERY 2.0
Page 131
THE OTHER ASPECT OF PERFORMANCE…
Page 132
ONCE LOADED, PERFORMANCE IS WAY BETTER!
Page 133
IF I’M GOING TO LEAVE APP OPEN ON MY DESKTOP I CARE WAY LESS ABOUT LOAD TIME
Page 134
"What about dual rendered a.k.a. isomorphic apps?"
Page 135
ARGUABLY "PORTABLE JS"
IS A BETTER WORD
Page 136
JUST A CLIENTSIDE APP WITH AN OPTIMIZED
INITIAL RENDER
Page 137
GOING FULL-ISOMORPHIC RENDERING, WITH USER DATA
AND ALL…
Page 138
OFTEN REQUIRES DRAMATICALLY
MORE COMPLEX CODE
Page 139
THERE ARE SOME CASES WHERE IT MAKES SENSE
Page 140
WITH STATE OF TOOLING TODAY
OFTEN NOT WORTH THE COMPLEXITY
Page 142
DOESN’T HAVE TO BE ALL OR NOTHING
Page 143
WE CAN PRE-RENDER EVERYTHING THAT’S NOT USER-SPECIFIC DATA
Page 144
WE CAN DO THIS AS A FULLY STATIC SITE
Page 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:
Page 147
APPS USUALLY HAVE: 1. public/marketing pages 2. all the stuff behind the login
Page 148
WRITE "PUBLIC" PAGES AND APP LAYOUT HTML
AS ISOMORPHIC COMPONENTS
Page 149
PRE-RENDER THEM TO STATIC PAGES AT BUILD TIME!
Page 150
SLIP IN THE BUILT JS BEFORE: </body>
Page 151
index.html: public home page 200.html: application layout
Page 152
Isomorphic Rendering™It’s not quite
Page 153
LazyMorphic Rendering™It’s more like
Page 154
COULD POTENTIALLY EVEN DO THIS FOR DYNAMIC/PUBLIC DATA
Page 155
THINK ABOUT WHAT WE GET
Page 156
pixels on the screen immediately
Page 157
TOTALLY CRAWLABLE (SEO)
Page 158
JS TAKES OVER ROUTING WHEN LOADED
Page 159
DEPLOYMENT AND OPS BECOME AS SIMPLE AS FTP
Page 160
WRITE 1 VERSION OF YOUR APP GET 90% OF BENEFIT FROM ISOMORPHIC RENDERING
Page 161
USERS WILL END UP WITH A PRIMED CACHE JUST BY VISITING YOUR
MARKETING PAGES
Page 162
READY FOR: PHONEGAP/CORDOVA
DESKTOP APP
Page 163
NOW WE HAVE AN APP WITH A SINGULAR CONCERN:
PRESENTATION
Page 164
WE’RE USING PURE WEB TECHNOLOGIES
Page 165
I’VE STARTING BUILDING ALL MY APPS AS STATIC
NATIVE WEB APPS
Page 167
FOR SO LONG THE TREND HAS BEEN TOWARD COMPLEXITY
Page 169
MY FUTURE INSIGHT
REGARDING "WEB APPS"?
Page 170
GOING BACK TO SIMPLE
Page 171
GOING BACK TO THE STATIC WEB
Page 172
STATIC NATIVE WEB APPS
Page 173
POWERED BY SERVICES SOME WHICH WE BUILD
MANY OF WHICH WE RENT
Page 174
surge.sh hood.ie
firebase.com auth0.com
divshot.com
Page 175
SIMPLE OPEN SOURCE EXAMPLE: HubTags.com
Page 176
•React •Ampersand.js •Webpack (hjs-webpack) •GitHub API •Surge.sh
Page 177
learn.humanjavascript.com
5-Hour Video Tutorial showing line by line how to build that app
Page 178
“So what about all these clientside frameworks anyway?”
Page 180
~30 DEVS LOTS OF JS
LOTS OF APPS
Page 181
FLEXIBILITY IS VITAL
Page 182
TOO RISKY TO GO “ALL-IN”
Page 183
FLEXIBILITY MODULARITY SO WHAT?!
Page 184
FRONTENDS ARE NOT AS DISPOSABLE AS THEY ONCE WERE
Page 185
MODULARITY LETS YOU REMODEL
THE KITCHEN WITHOUT BURNING DOWN THE
WHOLE BUILDING
Page 188
THE NAME "ampersand.js"
IS A FILTHY LIE
Page 189
BECAUSE NO SUCH FILE EXISTS!<script src="ampersand.js"></script>
Page 190
WE JUST NAMED IT SOMETHING SO IT’S EASIER TO TALK ABOUT
Page 191
THERE’S NOTHING YOU CAN DROP INTO A SCRIPT TAG WITHOUT A BUILD STEP
Page 192
SEPARATE COMMON.JS MODULES
Page 193
INDIVIDUALLY INSTALLED VIA NPM
Page 194
BUILD WITH BROWSERIFY OR WEBPACK
Page 195
THERE IS NO “CORE”
Page 196
ampersand-state ampersand-model ampersand-collection ampersand-rest-collection ampersand-view ampersand-router
Page 197
INDIVIDUAL GITHUB REPOS
Page 199
ONLY SEND CODE YOU USE
Page 200
MIX AND MATCH WHAT YOU WANT
Page 201
WhatsApp:
ampersand-state w/ react
Page 202
FlipKart
ampersand-* React
Page 203
Yahoo!
ampersand-router
Page 205
HOW CAN WE BE SURE WE’RE BUILDING WITH
THE RIGHT TOOLS?!
Page 207
WHAT DO WE KNOW?
Page 208
THINGS WILL CHANGE
Page 209
OPTIMIZE FOR MODULARITY
Page 210
OPTIMIZE FOR SIMPLICITY
Page 211
SEPARATING CONCERNS
Page 213
COMPLETELY STATIC FRONT END
Page 214
BUILDING MICROSERVICES TO ENABLE THAT TYPE OF APP
Page 215
LET’S KEEP PUSHING FOR SIMPLICITY
Page 216
OPTIMIZE FOR CHANGE. IT IS THE ONLY CONSTANT.
Page 217
THANKS!@HenrikJoreteg, andyet.com