London JS: The State of JavaScript

Transcript

1. The State of JavaScript

2. @Jack_Franklin

3. None

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

10. None

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
16. None

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

23. None

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

37. None

38. no framework is good at everything no framework is bad

    at everything

39. libraries vs frameworks

40. None

41. npm unified package publication

42. proper dependency management and versioning!

43. None

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

54. None

55. testing grounds

56. =>

57. None
58. None

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