Slide 1

Slide 1 text

Complexity Etc. @HenrikJoreteg

Slide 2

Slide 2 text

THIS USED TO BE SIMPLE!

Slide 3

Slide 3 text

1. WRITE SOME HTML 2. LAY IT OUT WITH FRAMES OR TABLES 3. FTP IT TO A SERVER! 4. BAM!

Slide 4

Slide 4 text

CONGRATULATIONS, YOU’RE A WEB DEVELOPER!

Slide 5

Slide 5 text

THEN IT GOT HARDER

Slide 6

Slide 6 text

WHO’S WRITTEN THEIR OWN BLOG SOFTWARE?

Slide 7

Slide 7 text

OVER ENGINEERING A BLOG WAS A RITE OF PASSAGE

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

CONGRATULATIONS, YOU’RE A WEB DEVELOPER!

Slide 10

Slide 10 text

PHEW!!

Slide 11

Slide 11 text

THEN WE GOT "SMART"

Slide 12

Slide 12 text

USE A FRAMEWORK!!

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

OUR EXCESSIVLELY DYNAMIC BLOG… IS NOW BETTER ORGANIZED AND HAS MORE DEPENDENCIES

Slide 15

Slide 15 text

CONGRATULATIONS, YOU’RE A WEB DEVELOPER!

Slide 16

Slide 16 text

WHAT ABOUT TODAY?

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

CONGRATULATIONS YOU MIGHT BE A "WEB DEVELOPER"

Slide 19

Slide 19 text

WHAT DOES "WEB DEVELOPER" EVEN MEAN?

Slide 20

Slide 20 text

WHAT DOES "WEB APP" EVEN MEAN?

Slide 21

Slide 21 text

THE BROWSER ISN’T OUR RENDERER

Slide 22

Slide 22 text

THE BROWSER IS OUR RUNTIME

Slide 23

Slide 23 text

THE WEBVIEW IS OUR RUNTIME

Slide 24

Slide 24 text

MORE LOGIC MOVING TO FRONT-END JS

Slide 25

Slide 25 text

DEVS WITH DIFFERENT BACKGROUNDS CONVERGING ON JS

Slide 26

Slide 26 text

BRINGING THEIR PATTERNS AND PREFERENCES

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

SINGLE PAGE APPS

Slide 29

Slide 29 text

HUH?

Slide 30

Slide 30 text

SINGLE PAGE APPS

Slide 31

Slide 31 text

"NATIVE"

Slide 32

Slide 32 text

I’M A WEB DEVELOPER

Slide 33

Slide 33 text

NATIVE WEB APP

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

FUNDAMENTAL DISTINCTION…

Slide 36

Slide 36 text

THE BROWSER IS YOUR RUNTIME

Slide 37

Slide 37 text

SEND THE APP ITSELF TO THE BROWSER INSTEAD OF THE RESULT OF RUNNING IT

Slide 38

Slide 38 text

Slide 39

Slide 39 text

SHOULD WE EVEN BE DOING THIS?

Slide 40

Slide 40 text

SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?

Slide 43

Slide 43 text

{{ RAISE YOUR HAND }}

Slide 44

Slide 44 text

YES!

Slide 45

Slide 45 text

WHAT SERVICE ARE WE PROVIDING?

Slide 46

Slide 46 text

CONTENT?

Slide 47

Slide 47 text

CONTENT SHOULD JUST WORK™

Slide 48

Slide 48 text

NO REASON TO COMPLICATE THINGS THAT CAN BE SIMPLE

Slide 49

Slide 49 text

BUT THE WEB IS NO LONGER JUST ABOUT LINKED CONTENT!

Slide 50

Slide 50 text

THERE ARE CASES WHERE CLIENTSIDE FUNCTIONALITY IS THE CORE VALUE PROVIDED BY SERVICE

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

1. RENDERING 2. NETWORKING 3. FILE READ/WRITE 4. STORAGE 5. WEB AUDIO APIS 6. WEBGL 7. VOICE/VIDEO HIGH PERFORMANCE

Slide 56

Slide 56 text

BROWSERS ARE NOT DUMB DOCUMENT VIEWERS

Slide 57

Slide 57 text

MOST CAPABLE UBIQUITOUS RUNTIMES ON THE PLANET

Slide 58

Slide 58 text

I’M JUST GOING TO SAY IT:

Slide 59

Slide 59 text

THERE ARE TWO TYPES OF APPLICATIONS ON THE WEB

Slide 60

Slide 60 text

1. NATIVE WEB APPS

Slide 61

Slide 61 text

2. SERVER-SIDE WEB APPS

Slide 62

Slide 62 text

THEY ARE FUNDAMENTALLY DIFFERENT

Slide 63

Slide 63 text

AND THAT’S O.K.

Slide 64

Slide 64 text

ANYTHING WE CAN BUILD WITH WEB TECH I THINK WE SHOULD

Slide 65

Slide 65 text

EVEN IF WE CAN’T SUPPORT OLDER BROWSERS

Slide 66

Slide 66 text

THE WEB IS INFINITELY MORE OPEN THAN NATIVE PLATFORMS

Slide 67

Slide 67 text

USER EXPECTATIONS HAVE EVOLVED

Slide 68

Slide 68 text

THE WEB IS DOING PRETTY WELL ON DESKTOPS

Slide 69

Slide 69 text

THE WEB IS LOSING ON MOBILE

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

THE WEB IS LOSING ON EXPERIENCE

Slide 72

Slide 72 text

WE OFTEN PREFER NATIVE APPS TO THE WEB

Slide 73

Slide 73 text

QUALITY AND POLISH OF USER EXPERIENCE IS OFTEN MUCH BETTER

Slide 74

Slide 74 text

LET’S FIX THIS!

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

SAYING THERE’S A DISTINCTION MAKES SOME PEOPLE MAD

Slide 77

Slide 77 text

"Everything should be an enhancement!"

Slide 78

Slide 78 text

WE’RE ON THE SAME TEAM!

Slide 79

Slide 79 text

WE WANT THE OPEN WEB TO WIN!

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

SHOULD WE NOT HAVE BUILT IT?

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

WHERE’S THE DOWNSIDE?

Slide 84

Slide 84 text

ACCESSIBILITY

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

SEO

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

PERFORMANCE

Slide 89

Slide 89 text

LET’S LOOK A BIT CLOSER AT TWITTER

Slide 90

Slide 90 text

WHAT IS TWITTER?

Slide 91

Slide 91 text

IS IT A WEB APP?

Slide 92

Slide 92 text

NO.

Slide 93

Slide 93 text

IT’S A SERVICE

Slide 94

Slide 94 text

APP != SERVICE

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

I DIDN’T REALLY CARE HOW THEY BUILT THEIR WEBAPP

Slide 97

Slide 97 text

BECAUSE I DIDN’T USE IT ANYWAY!

Slide 98

Slide 98 text

I WAS USING AN iOS APP!

Slide 99

Slide 99 text

THEIR WEB APP HAD ALREADY FAILED ME!

Slide 100

Slide 100 text

LET’S THINK ABOUT THIS

Slide 101

Slide 101 text

WHEN I FOLLOW A LINK TO A RANDOM TWEET ON MY PHONE…

Slide 102

Slide 102 text

JUST LET ME READ IT!

Slide 103

Slide 103 text

plain text I DON’T MIND IF IT’S

Slide 104

Slide 104 text

DON’T MAKE ME DOWNLOAD 2MB OF JS TO READ 140 CHARACTERS OF TEXT!

Slide 105

Slide 105 text

THIS IS THE PROBLEM THEY FIXED WITH NEW NEW TWITTER

Slide 106

Slide 106 text

BUT…

Slide 107

Slide 107 text

CATCHING UP WITH ALL THINGS TWITTER IS A FUNDAMENTALLY DIFFERENT USE CASE

Slide 108

Slide 108 text

FAILING TO RECOGNIZE DISTINCTION MAKES US FLOUNDER

Slide 109

Slide 109 text

A SERVICE CAN PROVIDE BOTH!

Slide 110

Slide 110 text

TWITTER.COM & TWEETDECK.COM

Slide 111

Slide 111 text

THERE’S STILL SOME GAPS BETWEEN WEB AND NATIVE

Slide 112

Slide 112 text

REAL OFFLINE SUPPORT

Slide 113

Slide 113 text

PLATFORMS THAT TREAT NATIVE WEB APPS AS FIRST CLASS CITIZENS

Slide 114

Slide 114 text

THOSE THINGS ARE CHANGING

Slide 115

Slide 115 text

1. SERVICE WORKER

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

THIS IS HUGE!

Slide 118

Slide 118 text

2. INSTALLABLE WEB APPS

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

"What about performance?"

Slide 122

Slide 122 text

WHITE PAGE OF DEATH

Slide 123

Slide 123 text

TIME TO FIRST PAINT

Slide 124

Slide 124 text

A PRIMED CACHE LARGELY INVALIDATES THIS ARGUMENT

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

MOST OF THESE TYPES OF APPS REQUIRE YOU TO BE LOGGED IN

Slide 127

Slide 127 text

PRE-FETCH OR EVEN PRE-RENDER THE ENTIRE APP ON PUBLIC PAGES OR LOGIN PAGE

Slide 128

Slide 128 text

NATIVE WEB APPS CAN STILL HAVE SMALL JS PAYLOADS!

Slide 129

Slide 129 text

ALL JS IN THE AMPERSAND.JS APP ON TODOMVC.COM COMBINED 28kb min + gzip

Slide 130

Slide 130 text

SMALLER THAN JQUERY 2.0

Slide 131

Slide 131 text

THE OTHER ASPECT OF PERFORMANCE…

Slide 132

Slide 132 text

ONCE LOADED, PERFORMANCE IS WAY BETTER!

Slide 133

Slide 133 text

IF I’M GOING TO LEAVE APP OPEN ON MY DESKTOP I CARE WAY LESS ABOUT LOAD TIME

Slide 134

Slide 134 text

"What about dual rendered a.k.a. isomorphic apps?"

Slide 135

Slide 135 text

ARGUABLY "PORTABLE JS" IS A BETTER WORD

Slide 136

Slide 136 text

JUST A CLIENTSIDE APP WITH AN OPTIMIZED INITIAL RENDER

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

OFTEN REQUIRES DRAMATICALLY MORE COMPLEX CODE

Slide 139

Slide 139 text

THERE ARE SOME CASES WHERE IT MAKES SENSE

Slide 140

Slide 140 text

WITH STATE OF TOOLING TODAY OFTEN NOT WORTH THE COMPLEXITY

Slide 141

Slide 141 text

HOWEVER…

Slide 142

Slide 142 text

DOESN’T HAVE TO BE ALL OR NOTHING

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

WE CAN DO THIS AS A FULLY STATIC SITE

Slide 145

Slide 145 text

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:

Slide 146

Slide 146 text

WOAH!

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

WRITE "PUBLIC" PAGES AND APP LAYOUT HTML AS ISOMORPHIC COMPONENTS

Slide 149

Slide 149 text

PRE-RENDER THEM TO STATIC PAGES AT BUILD TIME!

Slide 150

Slide 150 text

SLIP IN THE BUILT JS BEFORE:

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

Isomorphic Rendering™ It’s not quite

Slide 153

Slide 153 text

LazyMorphic Rendering™ It’s more like

Slide 154

Slide 154 text

COULD POTENTIALLY EVEN DO THIS FOR DYNAMIC/PUBLIC DATA

Slide 155

Slide 155 text

THINK ABOUT WHAT WE GET

Slide 156

Slide 156 text

pixels on the screen immediately

Slide 157

Slide 157 text

TOTALLY CRAWLABLE (SEO)

Slide 158

Slide 158 text

JS TAKES OVER ROUTING WHEN LOADED

Slide 159

Slide 159 text

DEPLOYMENT AND OPS BECOME AS SIMPLE AS FTP

Slide 160

Slide 160 text

WRITE 1 VERSION OF YOUR APP GET 90% OF BENEFIT FROM ISOMORPHIC RENDERING

Slide 161

Slide 161 text

USERS WILL END UP WITH A PRIMED CACHE JUST BY VISITING YOUR MARKETING PAGES

Slide 162

Slide 162 text

READY FOR: PHONEGAP/CORDOVA DESKTOP APP

Slide 163

Slide 163 text

NOW WE HAVE AN APP WITH A SINGULAR CONCERN: PRESENTATION

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

TOTALLY <3 IT!

Slide 166

Slide 166 text

FOR SO LONG THE TREND HAS BEEN TOWARD COMPLEXITY

Slide 167

Slide 167 text

No content

Slide 168

Slide 168 text

WHAT’S THE NEXT STEP IN THE EVOLUTION OF THE "WEB APP"?

Slide 169

Slide 169 text

GOING BACK TO SIMPLE

Slide 170

Slide 170 text

GOING BACK TO THE STATIC WEB

Slide 171

Slide 171 text

STATIC NATIVE WEB APPS

Slide 172

Slide 172 text

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

Slide 173

Slide 173 text

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

Slide 174

Slide 174 text

SIMPLE OPEN SOURCE EXAMPLE: HubTags.com

Slide 175

Slide 175 text

{{ DEMO }}

Slide 176

Slide 176 text

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

Slide 177

Slide 177 text

learn.humanjavascript.com 5-Hour Video Tutorial showing line by line how to build that app

Slide 178

Slide 178 text

AMPERSAND.JS

Slide 179

Slide 179 text

THE NAME "ampersand.js" IS A FILTHY LIE

Slide 180

Slide 180 text

BECAUSE NO SUCH FILE EXISTS!

Slide 181

Slide 181 text

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

Slide 182

Slide 182 text

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

Slide 183

Slide 183 text

SEPARATE COMMON.JS MODULES

Slide 184

Slide 184 text

INDIVIDUALLY INSTALLED VIA NPM

Slide 185

Slide 185 text

BUILD WITH BROWSERIFY OR WEBPACK

Slide 186

Slide 186 text

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

Slide 187

Slide 187 text

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

Slide 188

Slide 188 text

INDIVIDUAL GITHUB REPOS

Slide 189

Slide 189 text

STRICT SEMVER

Slide 190

Slide 190 text

todomvc.com

Slide 191

Slide 191 text

FLEXIBILITY MODULARITY SO WHAT?!

Slide 192

Slide 192 text

ONLY SEND CODE YOU USE

Slide 193

Slide 193 text

AMPERSAND TODOMVC: ~28kb min+gzip

Slide 194

Slide 194 text

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

Slide 195

Slide 195 text

Angular 2.0

Slide 196

Slide 196 text

MIX AND MATCH WHAT YOU WANT

Slide 197

Slide 197 text

WhatsApp: ampersand-state w/ react

Slide 198

Slide 198 text

FlipKart ampersand-* React

Slide 199

Slide 199 text

Yahoo! ampersand-router

Slide 200

Slide 200 text

BUT MODULARITY ISN’T THE ONLY FEATURE

Slide 201

Slide 201 text

ONE EXAMPLE OF WHY WE FORKED

Slide 202

Slide 202 text

SMARTER/STRICTER MODELS

Slide 203

Slide 203 text

var model = new Backbone.Model({ name: 'henrik' }); model.on('change:name', function () { console.log('new changed'); }); model.set({name: 'bob'}); Backbone Models

Slide 204

Slide 204 text

IF MODELS ARE OUR SOURCE OF TRUTH… WE WANT THEM TO BE MORE READABLE

Slide 205

Slide 205 text

YOU HAVE TO DEFINE WHAT YOU STORE

Slide 206

Slide 206 text

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

Slide 207

Slide 207 text

SESSION STATE: RELATED, NOT PERSISTED

Slide 208

Slide 208 text

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'}

Slide 209

Slide 209 text

GETTER/SETTER TRANFORMATIONS

Slide 210

Slide 210 text

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}

Slide 211

Slide 211 text

CACHED, OBSERVABLE DERIVED PROPERTIES

Slide 212

Slide 212 text

var Person = AmpState.extend({ props: { name: 'string' }, derived: { nickName: { deps: ['name'], fn: function () { return this.name.slice(0, 3); } } } });

Slide 213

Slide 213 text

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'

Slide 214

Slide 214 text

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

Slide 215

Slide 215 text

READ MORE IN DOCS http://ampersandjs.com

Slide 216

Slide 216 text

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

Slide 217

Slide 217 text

andyet.com

Slide 218

Slide 218 text

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

Slide 219

Slide 219 text

WE CAN’T!

Slide 220

Slide 220 text

WHAT DO WE KNOW?

Slide 221

Slide 221 text

THINGS WILL CHANGE

Slide 222

Slide 222 text

OPTIMIZE FOR MODULARITY

Slide 223

Slide 223 text

OPTIMIZE FOR SIMPLICITY

Slide 224

Slide 224 text

STATIC NATIVE WEB APPS

Slide 225

Slide 225 text

BUILDING MICROSERVICES TO ENABLE THAT TYPE OF APP

Slide 226

Slide 226 text

OPTIMIZE FOR CHANGE. IT IS THE ONLY CONSTANT.

Slide 227

Slide 227 text

LET’S KEEP PUSHING FOR SIMPLICITY

Slide 228

Slide 228 text

THANKS! @HenrikJoreteg, andyet.com