$30 off During Our Annual Pro Sale. View Details »

keeping up with javascript

jnwng
August 19, 2016

keeping up with javascript

talk given at react.js sf bay area meetup, 8/19/2016 at coursera

jnwng

August 19, 2016
Tweet

More Decks by jnwng

Other Decks in Technology

Transcript

  1. keeping up with javascript ReactJS SF Bay Area Meetup

  2. jon wong @jnwng frontend infrastructure

  3. javascript is moving at the speed of light, and it

    can feel overwhelming to keep up.
  4. i’m going to share four things to help you on

    your journey in javascript.
  5. 1) when to move fast 2) when to move slowly

    3) the importance of infrastructure 4) goed gereedschap is ‘t halve werk
  6. 1) when to move fast

  7. almost 50 courses about 20 engineers PHP, Backbone, and Bootstrap

    2012 the beginning of Coursera
  8. back then, building versus buying was easy, because there wasn’t

    much to buy.
  9. back then, building versus buying was easy, because there wasn’t

    much to buy. we built to our needs, so our needs were met.
  10. 2015 that awkward teenage phase. hundreds of courses about 40

    engineers Scala, PHP, Backbone
  11. what did we need? better accessibility for learners our pages

    took way too long to load
  12. what did we need? better accessibility for learners our pages

    took way too long to load reduced cognitive load for devs it was difficult to model state changes, it was difficult switching between templating and business logic.
  13. what did we need? better accessibility for learners our pages

    took way too long to load better performance using backbone / jQuery to deal with DOM manipulation and large applications wasn’t exactly performant reduced cognitive load for devs it was difficult to model state changes, it was difficult switching between templating and business logic.
  14. what did we need? better accessibility for learners our pages

    took way too long to load better performance using backbone / jQuery to deal with DOM manipulation and large applications wasn’t exactly performant documentation we rolled our own tools but didn’t get around to documenting them. reduced cognitive load for devs it was difficult to model state changes, it was difficult switching between templating and business logic.
  15. what we got from react better accessibility for learners server-side

    rendering can bring page loads from ~30s down to sub-single digits
  16. what we got from react better accessibility for learners server-side

    rendering can bring page loads from ~30s down to sub-single digits reduced cognitive load for developers declarative API means less logic to test and more easily expressed
  17. what we got from react better accessibility for learners server-side

    rendering can bring page loads from ~30s down to sub-single digits better performance rendering algorithm only changes what needs to be changed, and nothing more reduced cognitive load for developers declarative API means less logic to test and more easily expressed
  18. what we got from react better accessibility for learners server-side

    rendering can bring page loads from ~30s down to sub-single digits better performance rendering algorithm only changes what needs to be changed, and nothing more documentation many examples on the internet, lots of support should something go wrong. reduced cognitive load for developers declarative API means less logic to test and more easily expressed
  19. moving fast worked because we: • knew what we needed

  20. moving fast worked because we: • knew what we needed

    • found a tool that clearly resolved that need
  21. moving fast worked because we: • knew what we needed

    • found a tool that clearly resolved that need • communicated that change well
  22. 2) when to move slowly

  23. our simple applications became complex ones, and dealing with data

    became a problem.
  24. we heard about something called FLUX that might solve our

    problems.
  25. mid 2015 the Great Flux Wars

  26. needless to say, there were a lot of choices alt

    redux facebook-flux flummox fluxette fluxury fluxxor lux marty mcfly nuclear-js reflux fluxible
  27. so how did we choose?

  28. so how did we choose? just like our react decision,

    we moved fast.
  29. 2) when to move slowly

  30. every team chose their own adventure.

  31. every team chose their own adventure. every team ended up

    solving the same problems over and over again.
  32. every team chose their own adventure. every team ended up

    solving the same problems over and over again. and we ended up with five different versions of Flux in our codebase.
  33. this was not a successful process because we • didn’t

    know what we needed
  34. this was not a successful process because we • didn’t

    know what we needed • didn’t understand the purpose of the tool
  35. this was not a successful process because we • didn’t

    know what we needed • didn’t understand the purpose of the tool • rushed our decision process
  36. core architectural decisions require time and patience to fully evaluate

    their impacts.
  37. core architectural decisions require time and patience to fully evaluate

    their impacts. in short, we needed to move slowly.
  38. 3) the importance of infrastructure

  39. its 2016. we’re adults now, i swear! ~1300 courses ~65

    engineers Scala & React
  40. web infrastructure, presentation infrastructure, client infrastructure, product infrastructure, UI infrastructure,

    developer infrastructure, frontend infrastructure…
  41. web infrastructure, presentation infrastructure, client infrastructure, product infrastructure, UI infrastructure,

    developer infrastructure, frontend infrastructure… ...whatever you call them, there they are.
  42. being deliberate about your frontend infrastructure can have a huge

    impact
  43. some issues that come up between teams • inconsistency •

    solving the same problems over and over • difficulty making changes
  44. our team developed opinions on how you should build web

    apps at coursera: we call it the One Way™
  45. reduce the amount of choices to be made to focus

    on the part that matters: the product. what is the One Way™? guidelines and constraints
  46. reduce the amount of choices to be made to focus

    on the part that matters: the product. what is the One Way™? guidelines and constraints moving teams should be like moving between states, not moving between countries. consistency across teams
  47. reduce the amount of choices to be made to focus

    on the part that matters: the product. what is the One Way™? guidelines and constraints clearly set expectations moving teams should be like moving between states, not moving between countries. consistency across teams set every developer up for success by laying down how to be successful.
  48. reduce the amount of choices to be made to focus

    on the part that matters: the product. what is the One Way™? guidelines and constraints clearly set expectations moving teams should be like moving between states, not moving between countries. improvements can easily be rolled out across the stack, impact is immediate and noticeable. a tool for change consistency across teams set every developer up for success by laying down how to be successful.
  49. this has been successful so far because • we’re spending

    the time to understand our problems and their solutions.
  50. this has been successful so far because • we’re spending

    the time to understand our problems and their solutions. • we’re wasting less time fighting our tools
  51. this has been successful so far because • we’re spending

    the time to understand our problems and their solutions. • we’re wasting less time fighting our tools • we can communicate solved problems across the frontend organization
  52. 4)

  53. in english: good tools are half the work.

  54. you can’t spend all your time thinking about the tools,

    and ignore the people using them.
  55. do developers know both how and why to use these

    tools? some questions you should be asking:
  56. are things changing too much? some questions you should be

    asking: do developers know both how and why to use these tools?
  57. are things changing too much? how can we make everyone

    better engineers? some questions you should be asking: do developers know both how and why to use these tools?
  58. have a time for people to discuss the things they’re

    having trouble with. some things we do that you should do too biweekly forums
  59. have a time for people to discuss the things they’re

    having trouble with. some things we do that you should do too biweekly forums be approachable. share the things you’ve learned with those around you. sit in a common area
  60. have a time for people to discuss the things they’re

    having trouble with. some things we do that you should do too biweekly forums go back to product be approachable. share the things you’ve learned with those around you. sit in a common area you can’t fix pain points if you don’t know what they are, and you can’t rely on just what you hear - you need to feel it too.
  61. 1) when to move fast 2) when to move slowly

    3) the importance of infrastructure 4) goed gereedschap is ‘t halve werk (good tools are half the work)
  62. thanks!

  63. questions?