The State of JavaScript

Jack Franklin treats us to his talk on 'The State of JavaScript', where he explores, discusses and criticises the current state of web development with JavaScript.

Transcript

1. The State of JavaScript 1
2. this.setState('javascript', talk()); 2
3. Jack Franklin Frontend NE, August 2016 3
4. @pusher 4
7. I've spent the last ten months as a developer evangelist 7
8. This means I've talked to a lot of developers. 8
9. Given ~ 20 or so talks 9
10. And listened to many, many more 10
11. Teaching —ES2015 —React —Elm (!) 11
12. Thoughts and Opinions 12
13. It's basically me rambling for a bit 13
14. The State of JavaScript 14
15. Or: a series of things that I've been thinking about. 15
16. Or: how we keep getting it wrong and then getting it right 16
17. ! 17
18. Never been a better time 18
19. JavaScript gets a lot of stick, some of it deserved 19
20. [1, 2, 3].map(parseInt) // => [1, NaN, NaN] ! 20
21. But it's still the best language ever 21
22. Browers are getting more powerful 22
23. More and more APIs being added 23
24. The native DOM API isn't complete crap! 24
25. Low Level APIs 25
26. Service Worker vs App Cache https://vimeo.com/album/3953264/video/165995029 26
27. App Cache High Level, does one thing, hard to customise / control 27
28. Service Worker —Low level —Less functionality "out of the box" —Developers get full control 28
29. NodeJS 29
30. Learning as an industry 30
31. Native learning from frameworks 31
32. document.querySelectorAll 32
33. => from CoffeeScript 33
34. Object.observe 34
35. 1. Two way data binding is great but needs dirty checking which is...dirty 2. Let's implement Object.observe natively to deal with this 3. Oh hey, ReactJS! 35
36. Object.observe No More 36
37. Cumulative learning from competing frameworks 37
38. MVC doesn't work for client side applications, even though it's great on the server. 38
39. It was a logical starting point; we knew no better. 39
40. We tried it and we learned 40
41. Angular 1.X moved heavily to components. Ember 2 removed controllers. React only has components. 41
42. Web Components <chat-app name="Jack"></chat-app> 42
43. https://blog.pusher.com/realtime-web-components/ 43
45. ES2015 was a mess 45
46. A fantastic, feature heavy mess 46
47. ES2015 advances the language hugely 47
48. But it came at a cost of overwhelming developers 48
49. 50+ New features in ES20151 1 I got bored of counting... 49
50. Some features are loved —Promise makes async code a bit more intuitive —Arrow fns make scope intuitive —let makes bindings intuitive 50
51. Some features have that JS Quirk (TM) const person = { name: 'Jack', age: 24, supports: 'Newcastle' } 51
52. It's a const, right? person.supports = 'Sunderland' 52
53. Well then... console.log(person); // => { name: 'Jack', age: 24, supports: 'Sunderland' } 53
54. And some are less loved... class Crockford extends IDontLikeThis { constructor() { this.mistake = true; } } 54
55. 2 New features in ES2016 55
56. Array.prototype.includes 56
57. Was going to be called contains, but MooTools adds Array.prototype.contains... 2 2 https://esdiscuss.org/topic/having-a-non-enumerable-array-prototype-contains-may-not-be-web- compatible 57
58. ** (exponatiation) 58
59. The new process works 59
60. —Stage 0: strawman —Stage 1: proposal —Stage 2: draft —Stage 3: candidate —Stage 4: finished http://www.2ality.com/2015/11/tc39-process.html 60
61. Each year any stage 4 proposals are taken into JS 61
62. Yearly, small releases 62
63. Easy to keep up with, easy to know browser support 63
64. Get notified of new features when they are voted in 64
65. Async / Await in ES2017 65
66. // returns a Promise function getUser() {...} async function logUser() { let user = await getUser(); console.log('USER!', user); } 66
67. Looks sync, is async ! 67
68. Transpilers 68
71. ES2015 support —Edge 14: 90% —Chrome 52 / Opera 39: 98% —FF 49: 93% —Safari 10: 100% (kinda, read on...) —Node 6: 93% 71
72. Note: "100% ES2015 support" is misleading —ES2015: the module syntax —Not specced: module loading (Yes, this is really confusing!) 72
73. A browser can claim 100% ES2015 support, like Safari 10 And it's technically true. But kinda, not really. 73
74. Will we ever be rid of transpilers? 74
76. It depends on your target 76
77. And how hipster you want to be 77
78. Transpilers play a huge role in the JS proposal process 78
80. ! —Developers can try out new features ahead of time —Feedback loop is shortened —JS proposals don't feel so far away 80
81. ! —Developers leaning on features that might not exist 81
82. Be wary of depending on Babel plugins for early stage proposals Or at least, be prepared for a rewrite. 82
83. Proposals in stage 3+ are almost certain to make it through 83
84. Proposals in stage 2 are most likely going to make it 84
85. Side note: Object.observe made it into Chrome before it was binned 85
86. Do you need Babel? 86
87. —Edge 14: 90% —Chrome 52 / Opera 39: 98% —FF 49: 93% —Safari 10: 100% (kinda) —Node 6: 93% 87
88. Node 6: (nearly) full ES2015 support babel-preset-node6 OR: no Babel depending on what features you need. 88
89. Will we be using transpilers forever? 89
90. If you want to stick right on the cutting edge and use features before they are in browsers, yes. 90
91. If you're happy to use a subset of new features, or lucky enough to target "modern" browsers, no. 91
92. Once ES2015 is fully supported across all browsers most people build for, less people will use transpilers 92
93. TypeScript, Elm and others 93
94. ES2015 had three goals: —better for complex web applications —better for library authors —better as a target language 94
95. On the shoulders of CoffeeScript 95
96. If you're going to transpile, why not add more? 96
97. Types are great! Take learnings from other languages / ecosystems and apply them to JavaScript. 97
98. This will keep happening Varying levels of "transpilerness": —Babel (ES features + JSX) —TypeScript (Superset of JS) —Elm (WTF IS GOING ON) 98
99. Nothing wrong with a compile-to-JS language But be wary of the tradeoffs. 99
100. As always, it depends! 100
101. <br /> 101
102. Modules! 102
103. NodeJS is dreamy $ npm install x // index.js var x = require('x'); $ node index.js 103
104. 1. Install a package. 2. Use it. 104
105. That's what we want in the browser. 105
106. ES2015 modules in the browser 3 <script type="module"> import { fn } from './lib'; import React from 'http://cdn.com/react.js'; </script> 3 not yet supported across browsers 106
107. Guy Bedford, PolyConf4 4 https://www.youtube.com/watch?v=cRSBi1EAOCo 107
109. ES2015 imports and exports are static 109
110. // nooooppee if (x) { import React from 'react'; export { y }; } 110
111. Use map from Lodash: var _ = require('lodash'); _.map(...); Then: some-bundle-tool app.js > bundle.js Included: —your code —ALL of Lodash 111
112. In a fully ES2015 moduled world import { map } from 'lodash'; _.map(...); Then: some-bundle-tool app.js > bundle.js Included: —your code —Just lodash.map! 112
113. We're not there yet ES2015 module support is lacking across everywhere. 113
114. A fully ES2015 module web will be a much better one. 114
115. https://github.com/rollup/rollup 115
116. Tooling woes 116
118. JavaScript Fatigue = we're figuring this out 118
119. You have control here. 119
120. Find your preferred tool set. 120
121. Browserify, Webpack, jspm, others? 121
122. ES2015? Babel? 122
123. Stick with your toolchain 123
124. Evaluate every now and then 124
125. The baseline 125
126. Webpack is not the baseline Gulp / Grunt is not the baseline browserify is not the baseline React is not the baseline 126
127. <script> console.log('hello world'); </script> is the baseline 127
128. This should always be the baseline 128
129. Especially for beginners 129
130. And this is how we have to teach JavaScript 130
131. Layer your tools as you need to 131
132. But not before 132
133. Finding the right abstraction 133
134. React is an abstraction 134
135. The price of abstractions is a little indirection 135
136. The payoff is quicker, nicer and more enjoyable development 136
137. Nothing is free 137
138. Performance 138
139. https://developers.google.com/web/tools/chrome- devtools/profile/evaluate-performance/rail?hl=en 139
140. Paul Lewis: RAIL in the real world 5 5 https://www.youtube.com/watch?v=iIV1xPFXmBs 140
141. Progressive Web Apps 141
142. https://addyosmani.com/blog/getting-started-with- progressive-web-apps/ 142
143. ! Load Instantly (Service Worker) ! Add to Home Screen ! Web push notifications ! Secure ! Fast ! Responsive https://developers.google.com/web/progressive- web-apps/ 143
144. Offering a great mobile experience on the web 144
145. Flipkart, India’s largest e- commerce site, decided to combine their web presence and native app into a Progressive Web Application that has resulted in a 70% increase in conversions. 6 6 https://developers.google.com/web/showcase/2016/flipkart 145
146. Server Side Rendering 146
148. GoCardless is a universal ReactJS application 7 7 https://gocardless.com/blog/how-we-built-the-new-gocardless.com/ 148
149. Once the initial page is displayed, a request is made to fetch the rest of the site's React app. 149
150. All subsequent navigation is blindingly fast, not suffering the latency of HTTP requests since the browser already has the whole app. 150
151. If the user does not have JS, they still experience the fully rendered page and only miss out on the fast navigation. 151
152. —Ember Fastboot —Angular 2 Universal —And others (This isn't for every app!) 152
153. https://www.youtube.com/watch?v=Bb0Uk8c6ltQ 153
154. Is the web getting more complicated? 154
155. It depends 155
156. Is it hard work to build a performant, mobile friendly, offline first web application? 156
157. Yes 157
158. But that's exciting! 158
159. No one is making you build complex, progressive, offline first apps in the browser. 159
160. But there's lots of great reasons to 160
161. And if you spend the time and energy. 161
162. You'll get your rewards. 162
163. And have loads of fun in the meantime! 163
164. Thanks @Jack_Franklin javascriptplayground.com 164