Evolution of the "Web

Transcription

1 Evolution of the "Web

2 @Hoarse_JS

3 THIS USED TO BE SIMPLE!

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

5 CONGRATULATIONS, YOU RE A WEB DEVELOPER!

6 THEN IT GOT HARDER

7 WHO S WRITTEN THEIR OWN BLOG SOFTWARE?

8 OVER ENGINEERING A BLOG WAS A RITE OF PASSAGE

9 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

10 CONGRATULATIONS, YOU RE A WEB DEVELOPER!

11 PHEW!!

12 THEN WE GOT "SMART"

13 USE A FRAMEWORK!!

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

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

16 CONGRATULATIONS, YOU RE A WEB DEVELOPER!

17 WHAT ABOUT TODAY?

18 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

19 CONGRATULATIONS YOU MIGHT BE A "WEB DEVELOPER"

20 WHAT DOES "WEB DEVELOPER" EVEN MEAN?

21 WHAT DOES "WEB APP" EVEN MEAN?

22 THE BROWSER ISN T OUR RENDERER

23 THE BROWSER IS OUR RUNTIME

24 THE WEBVIEW IS OUR RUNTIME

25 MORE LOGIC MOVING TO FRONT-END JS

26 DEVS WITH DIFFERENT BACKGROUNDS CONVERGING ON JS

27 BRINGING THEIR PATTERNS AND PREFERENCES

28 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

29 SINGLE PAGE APPS

30 HUH?

31 SINGLE PAGE APPS

32 "NATIVE"

33 I M A WEB DEVELOPER

34 NATIVE WEB APP

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

36 FUNDAMENTAL DISTINCTION

37 THE BROWSER IS YOUR RUNTIME

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

39 <!doctype> <script src="app js"></script>

40 SHOULD WE EVEN BE DOING THIS?

41 SHOULD WE BUILD APPS THAT REQUIRE JAVASCRIPT?

42

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

52

53

54

55

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

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

82 WHERE S THE DOWNSIDE?

83 LET S LOOK A BIT CLOSER AT TWITTER

84 WHAT IS TWITTER?

85 IS IT A WEB APP?

86 NO.

87 IT S A SERVICE

88 APP!= SERVICE

89 twitter.com tweet deck tweetbot TWITTER ad dashboard android app ios app

90 I DIDN T REALLY CARE HOW THEY BUILT THEIR WEBAPP

91 BECAUSE I DIDN T USE IT ANYWAY!

92 I WAS USING AN ios APP!

93 THEIR WEB APP HAD ALREADY FAILED ME!

94 LET S THINK ABOUT THIS

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

96 JUST LET ME READ IT!

97 I DON T MIND IF IT S plain text

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

99 THIS IS THE PROBLEM THEY FIXED WITH NEW NEW TWITTER

100 BUT

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

102 FAILING TO RECOGNIZE DISTINCTION MAKES US FLOUNDER

103 A SERVICE CAN PROVIDE BOTH!

104 TWITTER.COM & TWEETDECK.COM

105 THERE S STILL SOME GAPS BETWEEN WEB AND NATIVE

106 REAL OFFLINE SUPPORT

107 PLATFORMS THAT TREAT NATIVE WEB APPS AS FIRST CLASS CITIZENS

108 THOSE THINGS ARE CHANGING

109 1. SERVICE WORKER

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

111 THIS IS HUGE!

112 2. INSTALLABLE WEB APPS

113 JSON-BASED WEB MANIFEST CHROME M39+ FIREFOX

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

115 "What about performance?"

116 WHITE PAGE OF DEATH

117 TIME TO FIRST PAINT

118 A PRIMED CACHE LARGELY INVALIDATES THIS ARGUMENT

119 1. GIVE IT A UNIQUE NAME <!doctype> <script src="app js"></script> 2. CACHE IT FOREVER HTTP/ OK Cache-Control: max-age=really BIG NUMBER! Content-Encoding: gzip

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

121 PRE-FETCH APP ON PUBLIC PAGES OR LOGIN PAGE

122 NATIVE WEB APPS CAN STILL HAVE SMALL JS PAYLOADS!

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

124 SMALLER THAN JQUERY 2.0

125 THE OTHER ASPECT OF PERFORMANCE

126 ONCE LOADED, PERFORMANCE IS WAY BETTER!

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

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

129 JUST A CLIENTSIDE APP WITH AN OPTIMIZED INITIAL RENDER

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

131 OFTEN REQUIRES DRAMATICALLY MORE COMPLEX CODE

132 THERE ARE SOME CASES WHERE IT MAKES SENSE

133 WITH STATE OF TOOLING TODAY OFTEN NOT WORTH THE COMPLEXITY

134 HOWEVER

135 DOESN T HAVE TO BE ALL OR NOTHING

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

137 WE CAN DO THIS AS A FULLY STATIC SITE

138 Route: Asset: site.com/pic.png -> pic.png site.com site.com/page site.com/asdf -> index.html -> page.html -> 404.html or 200.html

139 WOAH!

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

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

142 PRE-RENDER THEM TO STATIC PAGES AT BUILD TIME!

143 SLIP IN THE BUILT JS BEFORE: </body>

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

145 COULD POTENTIALLY EVEN DO THIS FOR DYNAMIC/PUBLIC DATA

146 THINK ABOUT WHAT WE GET

147 pixels on the screen immediately

148 TOTALLY CRAWLABLE (SEO)

149 JS TAKES OVER ROUTING WHEN LOADED

150 DEPLOYMENT AND OPS BECOME AS SIMPLE AS FTP

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

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

153 READY FOR: PHONEGAP/CORDOVA DESKTOP APP

154 NOW WE HAVE AN APP WITH A SINGULAR CONCERN: PRESENTATION

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

156 TOTALLY <3 IT!

157 FOR SO LONG THE TREND HAS BEEN TOWARD COMPLEXITY

158

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

160 GOING BACK TO SIMPLE

161 GOING BACK TO THE STATIC WEB

162 STATIC NATIVE WEB APPS

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

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

165 SIMPLE OPEN SOURCE EXAMPLE: HubTags.com

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

167 andyet.com

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

169 WE CAN T!

170 WHAT DO WE KNOW?

171 THINGS WILL CHANGE

172 BUILD MODULAR SYSTEMS THAT STRIVE TO BE AS SIMPLE AS THEY CAN BE

173 OFFLOADING PRESENTATION STATIC NATIVE WEB APPS

174 BUILDING MICROSERVICES TO ENABLE THAT TYPE OF APP

175 OPTIMIZE FOR CHANGE. IT IS THE ONLY CONSTANT.

176 LET S KEEP PUSHING FOR SIMPLICITY

177 LET S BUILD FOR THE FUTURE OF THE WEB, NOT ITS PAST

178 andyet.com