Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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. javascript is moving at the speed of light, and it

    can feel overwhelming to keep up.
  2. 1) when to move fast 2) when to move slowly

    3) the importance of infrastructure 4) goed gereedschap is ‘t halve werk
  3. back then, building versus buying was easy, because there wasn’t

    much to buy. we built to our needs, so our needs were met.
  4. 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.
  5. 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.
  6. 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.
  7. what we got from react better accessibility for learners server-side

    rendering can bring page loads from ~30s down to sub-single digits
  8. 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
  9. 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
  10. 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
  11. moving fast worked because we: • knew what we needed

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

    • found a tool that clearly resolved that need • communicated that change well
  13. needless to say, there were a lot of choices alt

    redux facebook-flux flummox fluxette fluxury fluxxor lux marty mcfly nuclear-js reflux fluxible
  14. every team chose their own adventure. every team ended up

    solving the same problems over and over again.
  15. 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.
  16. this was not a successful process because we • didn’t

    know what we needed • didn’t understand the purpose of the tool
  17. 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
  18. core architectural decisions require time and patience to fully evaluate

    their impacts. in short, we needed to move slowly.
  19. web infrastructure, presentation infrastructure, client infrastructure, product infrastructure, UI infrastructure,

    developer infrastructure, frontend infrastructure… ...whatever you call them, there they are.
  20. some issues that come up between teams • inconsistency •

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

    apps at coursera: we call it the One Way™
  22. 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
  23. 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
  24. 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.
  25. 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.
  26. this has been successful so far because • we’re spending

    the time to understand our problems and their solutions.
  27. 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
  28. 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
  29. 4)

  30. do developers know both how and why to use these

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

    asking: do developers know both how and why to use these tools?
  32. 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?
  33. 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
  34. 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
  35. 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.
  36. 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)