keeping up
with javascript
ReactJS SF Bay Area Meetup
Slide 2
Slide 2 text
jon wong @jnwng
frontend infrastructure
Slide 3
Slide 3 text
javascript is moving at
the speed of light, and it can feel
overwhelming to keep up.
Slide 4
Slide 4 text
i’m going to share four things to
help you on your journey
in javascript.
Slide 5
Slide 5 text
1) when to move fast
2) when to move slowly
3) the importance of infrastructure
4) goed gereedschap is ‘t halve werk
Slide 6
Slide 6 text
1) when to move fast
Slide 7
Slide 7 text
almost 50 courses
about 20 engineers
PHP, Backbone, and Bootstrap
2012
the beginning
of Coursera
Slide 8
Slide 8 text
back then,
building versus buying was easy,
because there wasn’t much to buy.
Slide 9
Slide 9 text
back then,
building versus buying was easy,
because there wasn’t much to buy.
we built to our needs,
so our needs were met.
Slide 10
Slide 10 text
2015
that awkward
teenage phase.
hundreds of courses
about 40 engineers
Scala, PHP, Backbone
Slide 11
Slide 11 text
what did we need?
better accessibility for learners
our pages took way too long to load
Slide 12
Slide 12 text
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.
Slide 13
Slide 13 text
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.
Slide 14
Slide 14 text
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.
Slide 15
Slide 15 text
what we got from react
better accessibility for learners
server-side rendering can bring page loads
from ~30s down to sub-single digits
Slide 16
Slide 16 text
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
Slide 17
Slide 17 text
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
Slide 18
Slide 18 text
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
Slide 19
Slide 19 text
moving fast worked because we:
● knew what we needed
Slide 20
Slide 20 text
moving fast worked because we:
● knew what we needed
● found a tool that clearly resolved
that need
Slide 21
Slide 21 text
moving fast worked because we:
● knew what we needed
● found a tool that clearly resolved
that need
● communicated that change well
Slide 22
Slide 22 text
2) when to move slowly
Slide 23
Slide 23 text
our simple applications became
complex ones, and dealing with data
became a problem.
Slide 24
Slide 24 text
we heard about something called
FLUX
that might solve our problems.
Slide 25
Slide 25 text
mid 2015
the Great
Flux Wars
Slide 26
Slide 26 text
needless to say,
there were a lot of choices
alt
redux
facebook-flux
flummox
fluxette
fluxury
fluxxor lux
marty
mcfly
nuclear-js
reflux fluxible
Slide 27
Slide 27 text
so how did we choose?
Slide 28
Slide 28 text
so how did we choose?
just like our react decision,
we moved fast.
Slide 29
Slide 29 text
2) when to move slowly
Slide 30
Slide 30 text
every team chose their own
adventure.
Slide 31
Slide 31 text
every team chose their own
adventure.
every team ended up solving the same
problems over and over again.
Slide 32
Slide 32 text
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.
Slide 33
Slide 33 text
this was not a successful process because we
● didn’t know what we needed
Slide 34
Slide 34 text
this was not a successful process because we
● didn’t know what we needed
● didn’t understand the purpose of
the tool
Slide 35
Slide 35 text
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
Slide 36
Slide 36 text
core architectural decisions require
time and patience
to fully evaluate their impacts.
Slide 37
Slide 37 text
core architectural decisions require
time and patience
to fully evaluate their impacts.
in short, we needed to move slowly.
Slide 38
Slide 38 text
3) the importance of infrastructure
Slide 39
Slide 39 text
its 2016.
we’re adults
now, i swear!
~1300 courses
~65 engineers
Scala & React
web infrastructure, presentation
infrastructure, client infrastructure,
product infrastructure, UI infrastructure,
developer infrastructure, frontend
infrastructure…
...whatever you call them,
there they are.
Slide 42
Slide 42 text
being deliberate about your
frontend infrastructure can have
a huge impact
Slide 43
Slide 43 text
some issues that come up between teams
● inconsistency
● solving the same problems over and over
● difficulty making changes
Slide 44
Slide 44 text
our team developed opinions on how you
should build web apps at coursera:
we call it the One Way™
Slide 45
Slide 45 text
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
Slide 46
Slide 46 text
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
Slide 47
Slide 47 text
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.
Slide 48
Slide 48 text
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.
Slide 49
Slide 49 text
this has been successful so far because
● we’re spending the time to understand our
problems and their solutions.
Slide 50
Slide 50 text
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
Slide 51
Slide 51 text
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
Slide 52
Slide 52 text
4)
Slide 53
Slide 53 text
in english:
good tools are half the work.
Slide 54
Slide 54 text
you can’t spend all your time
thinking about the tools, and
ignore the people using them.
Slide 55
Slide 55 text
do developers know both how and why to use
these tools?
some questions you should be asking:
Slide 56
Slide 56 text
are things changing too much?
some questions you should be asking:
do developers know both how and why to use
these tools?
Slide 57
Slide 57 text
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?
Slide 58
Slide 58 text
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
Slide 59
Slide 59 text
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
Slide 60
Slide 60 text
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.
Slide 61
Slide 61 text
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)