Pro Yearly is on sale from $80 to $50! »

London JS: The State of JavaScript

London JS: The State of JavaScript

Aea964cf59c0c81fff752896f070cbbb?s=128

Jack Franklin

May 27, 2015
Tweet

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