keeping up with javascript

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

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?