London JS: The State of JavaScript

Transcript

1. The State of JavaScript
2. @Jack_Franklin
4. https://gocardless.com/blog/how-we-built-the-new-gocardless.com/
5. things people keep tweeting 4
6. it’s difficult to get into front end web development 1
7. it’s difficult to get into front end web development it’s difficult to build client side applications
8. HTML + CSS + the odd bit of jQuery
9. complexity for complexity’s sake
11. it’s difficult to build client side applications 2
12. building client side applications is complex
13. http://www.smashingmagazine.com/2013/06/11/front-end-ops/ “application logic is being deferred to the client side. For some reason, though, operations folks aren’t going with it”
14. moving work to the client necessarily leads to a more involved, complex front end workflow (and that’s not a bad thing)
15. I constantly feel that I'm behind on my homework having to evaluate new libraries and frameworks showing up https://news.ycombinator.com/item?id=9604203 3
17. "But how can we get anything done when we’re spending most of our time learning?" http://www.breck-mckye.com/blog/2014/12/the-state-of-javascript- in-2015/
18. Stop trying to learn. Build things in whatever you’re comfortable with.
19. “As you get better, these new frameworks and tools become way less daunting and the anxiety caused by things moving too fast will subside.” http://wesbos.com/overwhelmed-with-web-development/
20. Focus on a higher level and remove the anxiety
21. deep knowledge of 1-2 tools you rely on is always superior
22. there are too many frameworks 4
24. in the last 12 - 24 months… backbone angular ember react
25. this is not a bad thing!
26. competition = improvement (ReactJS rendering)
27. “Why we moved from A to B and why A is rubbish”
28. pressure to be on the latest and greatest
29. use cases
30. don’t under value familiarity
31. GoCardless picked Angular
32. and now we’re quite good at it
33. “will you move from Angular to X?
34. https://roost.bocoup.com/2015/austin/blog/why-backbone/
35. so many considerations
36. https://twitter.com/padolsey/status/603203449803636737
38. no framework is good at everything no framework is bad at everything
39. libraries vs frameworks
41. npm unified package publication
42. proper dependency management and versioning!
44. ECMAScript 6 ECMAScript 2015
45. Release Candidate 4 https://people.mozilla.org/~jorendorff/es6-draft.html
46. goals of ES6 3
47. complex applications
48. libraries
49. code generation (compile to JS)
50. https://youtu.be/mPq5S27qWW8
51. block scoping arrow functions destructuring default parameters
52. adoption and familiarity
53. we’re not writing “straight up” JavaScript any more
55. testing grounds
56. =>
59. SystemJS
60. jspm http://javascriptplayground.com/blog/2014/11/js-modules-jspm- systemjs/
61. https://youtu.be/NpMnRifyGyw
62. http://www.bbc.co.uk/news/magazine-16444966
63. “Photographs will be telegraphed from any distance… striking events will be published… an hour later… photographs will reproduce all of nature’s colours.”
64. “Wireless telephone and telegraph circuits will span the world. A husband in the middle of the Atlantic will be able to converse with his wife sitting in her boudoir in Chicago.”
65. “There will be no C, X or Q in our everyday alphabet. They will be abandoned because unnecessary.”
66. things that will may (won’t) happen in JavaScript in the next 12-24 months… 8
67. …for complex web applications
68. fewer people will write JS without going through a compilation step 1
69. (TypeScript and Babel in particular)
70. Smaller libraries (and the composing of) will become more popular 2
71. Focus on libraries doing one thing well (MomentJS, Immutable) 3
72. The monoliths (Angular, Ember) will always have their place and use cases 4
73. The use of compilers like Babel will be abstracted away by build tools like jspm and Webpack 5
74. Running the same JS client side and server side will become more popular 6
75. and the phrase “Isomorphic JS” will die in a pit of fire 6.1
76. As ES6 implementations grow and stabilise, we’ll already be writing ES7 anyway 7
77. The rate of new frameworks will slow down 8
78. In 12 months, tweet me telling me how right wrong I was
79. @Jack_Franklin