►
Description
A tale of two front-end development environments: or how bend npm3 to your will by Kate Hudson
A
I'm
kate,
I'm
from
Mozilla
and
I
work
on
writing
features
and
experiments
in
Firefox
in
a
newfangled,
Webbie
style
of
JavaScript
that
sometimes
my
co-workers
get
kind
of
uncomfortable
about.
However,
I'm
super
excited
to
be
here
today,
because
I'm
going
to
talk
to
you
about
using
NPM
for
javascript
in
the
browser,
and
we
all
love
browsers
right,
yeah.
A
A
So
does
anyone
remember
the
web
back
in
the
late
90s?
This
was
like
when
your
phone
was
on
the
hook.
This
is
what
the
internet
looked
like.
Yes,
anybody,
late,
90s,
early
2000s,
anyone
writing
for
the
web.
Yeah!
If
you
were.
You
probably
remember
that
in
those
days,
javascript
was
definitely
not
something
you
would
have
conferences
about.
You
know
you
wouldn't
in
the
early
days
you
might
have
used
it
to
me
me
validate
a
form
or
more
likely
annoy
the
crap
out
of
people
with
pop-ups.
You
know
thanks
javascript.
A
In
fact,
people
hated
JavaScript
so
much.
They
actually
wrote
articles
about
how
much
it
sucked
so
I
went
on
the
Wayback
Machine
a
little
and
I
looked
for
this
so
blindly.
Accepting
a
high
level
of
security
risk
on
the
web
by
enabling
JavaScript
is
as
shaky
as
a
ride
on
the
Canadian
Space
Shuttle
made
of
birch
bark
and
pine
gum.
So
this
is
from
stupid,
Yeah
right,
stupid,
JavaScript
security
tricks
circa
in
1997,
and
this
really
hits
home
for
me
because
I'm,
Canadian
and
I
love
Java
scripts.
A
You
know
so
nowadays,
things
are
very
different
for
front-end
JavaScript.
We
have
an
incredible
open
source
community.
We
have
frameworks
that
are
used
by
millions
of
people,
robust
applications
and
not
so
robust
applications
that
are
used
by
billions
of
people.
You
know
some
people
even
work
for
companies
where
their
flagship
product
is
written,
at
least
partially
in
JavaScript.
Like
me,
yay
and
there's
a
lot
of
reasons
why
this
is
the
case
like
browser
standardization,
better
devtools,
you
know
code
sharing
platforms,
but
a
huge
part
of
it
is
thanks
to
node
and
NPM.
A
So
this
is
really
what
it
comes
down
to
you
in
order
to
do
first
class
work,
we
need
good
dependency
management,
okay
and
I.
Think
today,
by
far
npm
is
the
most
reliable,
flexible
and
powerful
solution
for
front-end
javascript.
This
is
true
whether
you're
writing.
You
know
a
newfangled
app,
that's
you
know
from
scratch
or
dealing
with
a
legacy
code
base,
and
I'm
going
to
show
you
what
that
looks
like
in
a
couple
of
different
code
bases.
But
first
I
want
to
tell
you
a
little
bit
more
about
myself.
A
You
know
I'm
Canadian,
so
I
really
like
cycling.
This
is
a
picture
of
me
at
a
bike
rally
with
about
500
other
people
fighting
for
bike
lanes
yeah
and
now
you
all
hate,
merely
Oh
cyclists.
So
this
is
a
picture
of
the
waterfront
near
my
house
in
downtown
Toronto
and
I.
Absolutely
love
it
because
it's
pretty
awesome
plate.
It's
a
pretty
awesome
place
to
commute
whether
you're
a
cyclist,
a
transit
user,
a
pedestrian
or
a
driver.
A
Anyone
been
to
Toronto
yay,
yay
Toronto,
so
like
more,
the
most
of
North,
America,
Toronto's,
road
and
highway
infrastructure
was
originally
built
to
support
cars
and
cars
alone,
and
some
of
our
politicians
like
to
remind
us
of
this
a
lot
which
is
cool
but,
as
our
city
has
grown
and
cycling,
and
public
transit
started
to
mature
as
an
alternative
mode
of
transportation.
We've
adapted
the
system
to
fit
the
needs
of
everyone,
not
just
cars
and
I.
Think
NPM
has
gone
through
a
similar
transition,
although
it
was
originally
designed
to
support
node.
A
It's
now
adopted
to
serve
a
much
broader
set
of
use
case,
so
something
that
I
hear
a
lot
from
the
people
at
NPM,
who
are
incredibly
talented
and
competent,
is
that
dependency
management
is
really
hard
to
get
right,
and
part
of
that
is
because
it's
obviously
a
huge
engineering
challenge,
but
I
think.
Another
reason
for
that
is
that
in
any
large
system
that
adopts
to
an
increasingly
diverse
set
of
users,
defining
the
right
way
to
do
things
becomes
much
more
nuanced.
This
is
true
about
software
as
much
as
it
is
about
good,
good
city
infrastructure.
A
So
when
it
comes
to
topics
like
performance,
reliability,
intuitive
design,
the
idea
that
things
should
just
work
out
of
the
box
people
have
really
different
opinions
about
what
that
means,
and
for
good
reasons,
and
when
those
opinions
collide
well,
sometimes
we
tend
to
react
in
a
somewhat
emotional
way
shall
we
say
so
in
Toronto,
for
example,
this
is
a
game
I
like
to
call
passive
aggressive
license,
plate
photography
or,
as
the
other
side
likes
to
call
it,
give
the
cyclist
the
finger.
So
you
know
difference
of
opinions
not
expressed
so
well.
A
Kinda
reminds
you
have
some
github
issues:
doesn't
it
yeah
this
one's
from
San
Francisco
just
yesterday,
so
I
like
to
think
that
we
can
do
better.
You
know,
there's
a
more
productive
approach
to
using
strategies
to
deal
with
our
unique
requirements
and
challenges
as
front
end
users
of
NPM.
So
let's
do
that?
Let's
talk
about
it,
so
I'm
going
to
start
off
start
us
off
with
an
example
of
a
brand
new
green
fields,
kind
of
project.
So
this
is
a
little
web.
App
called
bike
lane
go
and
it's
a
lot
like
a
popular
mobile
app.
A
You
might
be
familiar
with
so
go
emoji
all
right,
so
I
would
have
actually
really
liked
to
build
this.
But
unfortunately,
you
know
was
doing
Firefox
stuff
and
it's
only
theoretical.
So
if
you
want
to
go
ahead
and
do
it
I'll
be
your
biggest
fan?
Okay,
all
right!
So
what
we're
going
to
do
with
this?
We
can
use
any
module
loader
we
want,
which
is
great.
We're
going
to
use
react
for
the
UI,
because
why
not
and
we're
going
to
use,
maybe
that
getusermedia
Web
API.
A
We
have
to
make
sure-
and
this
is
important-
that
it's
small
and
fast
enough
to
run
properly
on
mobile
phones,
so
to
start
things
off
we're
going
to
make
a
directory
and
we're
going
to
go
into
it.
We're
going
to
NPM
in
it,
which
you've
already
heard
from
other
speakers
about.
So
you
know
what
that
does
we're
going
to
NPM
install
all
the
dependencies
we
need
for
our
appt
okay.
So
there
we
go,
react
everything
react
you
know
yeah.
So
you
know
this
is
everything
we
need.
A
So
you
know
you're
going
to
need
more,
but
this
is
a
good
start.
So
so
far,
nothing
different
from
note.
We've
done
exactly
what
you
do
if
you're
writing,
pokemon
or
sorry
oops,
a
bike
lingo,
you
know
server.
It's
the
same
thing
where
we
first
start
to
diverge
from
how
things
work
in
node
is
module
loading.
So
a
node.
We
have
a
simple
module:
loader,
that's
built
into
core
that
works
out
of
the
box
with
NPM,
which
is
awesome,
and
you
probably
know
it
as
the
require
function.
A
If
you've
never
looked
at
some
of
the
source
code
for
the
module
stuff,
it's
pretty
interesting,
I
highly
recommend
it.
Maybe
the
browser
as
of
right
now
we
don't
yet
have
an
implemented
standard
for
module
loading,
at
least
one
that
we
have
across
the
board
and
our
constraints
are
very
different,
so
note
when
we
call
require
we
load
in
cash
modules
from
the
file
system.
You
know
when
we
start
the
program
up,
but
we
only
have
to
do
this
one,
because
we
only
have
to
do
this
ones.
A
That
start
up,
and
you
know
we
tend
to
use
high-powered
machines,
the
cost
of
installing
and
loading
a
large
number
of
files
is
pretty
minimal,
that's
fine,
but
in
the
browser,
on
the
other
hand,
we
don't
have
a
file
system
to
work
with.
We
need
to
rely
on
users
to
load
resources
from
the
network,
so
at
the
bare
minimum
it
means
we
need
to
transform
our
file
system
of
source
modules
into
a
resource
browsers
understand
how
to
fetch.
A
Another
thing
we
have
to
do,
though,
is
to
be
mindful
of
our
users,
particularly
on
mobile
devices,
so
we
need
to
make
sure
reducing
the
size
and
content
are
fought
of
our
files
to
what's
absolutely
necessary.
You
know
we
need
to
reduce
the
number
of
HTTP
requests
at
least
right
now,
and
we
need
to
be
able
to
deal
with
partial,
fail
years
or
slow
connections.
A
If
you're
wondering
we
do
have
a
specification
for
modules
in
es2015
that
defines
a
new
syntax,
so
the
import
in
the
export
declarations,
as
well
as
an
implementation
of
a
loader,
that's
actually
in
progress
in
several
browsers,
including
Firefox,
but
today
I'm
going
to
be
talking
about
strategies.
You
can
go
home
and
use
right
now
in
the
future.
We'll
probably
use
a
combination
of
built-in
browser
features
as
well
as
tools
from
userland
in
order
to
continue
to
integrate
into
the
npm
ecosystem,
because
that's
the
best
way
to
do
the
web
right.
A
That
was
for
my
boss,
yeah.
So
speaking
of
user
land,
you
know,
there's
a
quite
a
few
module
loader
implementations.
You
can
use
for
front-end
implementation,
front-end
integration
with
NPM,
so
one
of
the
more
popular
ones
these
days
is
web
pack.
So
I'm
going
to
show
you
that
today,
with
our
example
so
with
web
pack,
you
know
it
allows
us
to
import
modules
synchronously
with
a
require
function.
There's
also
a
way
to
do
it
asynchronously,
but
we're
going
to
stick
with
this.
A
We
can
also
use,
as
a
web
pack
to
native
es2015
module
definition
syntax
if
you
prefer,
which
is
totally
cool
or
web
pack.
Difference
differs
from
nodes
module.
Loader
is
an
instead
of
importing
files
at
runtime.
Web
pack
has
a
compile
step
that
transforms
your
files
into
functions
in
a
single
file
or
a
set
of
chunks
which
can
be
executed
as
needed.
So
you
know,
as
we
can
see
here,
we
end
up
with
a
single
j/s
file,
main
bundle
jas,
and
we
link
that
in
the
HTML
page
of
our
bike,
lane
go
app.
A
So
that's
really
awesome
because
it's
saving
us
HTTP
requests.
So
what
about
NPM
so
by
default?
Web
pack
will
resolve
relative
paths
relative
to
the
file
and
absolute
paths
relative
to
node
modules.
If
you
want,
you
can
actually
add
your
own
configuration
for.
You
know
resolving
stuff
into
other
folders.
So,
for
example,
if
I
do
my
source
directory
in
this
resolve
setting,
it
will
first
look
for
modules
in
source
and
then
we'll
fall
back
to
node
modules.
We
can't
find
it
so
that's
pretty
cool
so
for
our
bike
lane
go
up.
A
Here's
our
main
J
we're
requiring
react.
You
know
we've
got
a
single
component
and
we're
rendering
it.
We
also
have
this
like
awesome.
Necessary
plugin
called
react
instinct.
Oh
yes,
we
need
it
so,
but
if
we
look
at
our
node
modules
directory,
including
all
of
our
dev
dependencies,
it's
about
47
megabytes,
combined,
which
you
know
if
you
end
up
loading
a
site
that
was
47
megabytes.
A
Well,
let's
just
put
this
way:
it's
not
going
to
load
right.
So
if
we
read
one
pack,
just
you
know
straight
off
of
our
configuration.
Our
battle
is
about
800
cabe
and
that's
because
webpack
actually
only
includes
files
that
have
been
explicitly
called
from
our
source
code.
So
that's
better
mine.
It's
great.
We
can
load
external
dependencies
and
it's
working.
It
would
totally
run
at
this
point.
A
But
honestly,
if
you
go
out
into
the
world
with
an
800
k,
javascript
file
that
just
has
reactant
like
one
plugin
in
it,
I'm
going
to
be
really
sad
and
you're
going
to
be
really
sad.
So
don't
do
it.
So,
let's
figure
out
you
know
we'll
look
at
react
specifically,
since
it's
a
pretty
large
and
common
dependency.
Let's
analyze
this
problem,
so
without
webpack
the
development,
a
build
of
reaction
is
about
687
k,
so
that's
a
development
build
and
the
production
build
is
about
145.
Our
bundle
is
800
k.
So
there's
something
going
on
here.
A
So
it
sounds
like
a
job
for
the
bundle
detective.
You
know
the
truth
is
out
there.
Yes,
so
the
first
tool
I
like
to
use
as
a
bundle
detective
is
to
start
with
web
pack,
since
web
pack
is
focused
on
the
files
that
we're
actually
executing
and
use
the
dash
dash
jason
output
parameter.
So
what
that
actually
does?
Is
it
on
output,
stats
for
all
chunks
and
modules,
including
the
size
and
the
dependency
tree
of
each
one?
So
you
know
this
is
only
for
files
included
into
brundle-
it's
not
very
usable
in
this
state.
A
So
let's
look
at
what
we
can
do
with
that.
There's
actually
a
tool
on
web
packs
website
that
you
can
upload
stats
to
it
and
it
will
visualize
them.
So,
basically,
you
just
upload
it
and
yeah
it
sort
of
creates
this
really
awesome.
Spider
thing
that
looks
really
cool.
It's
not
particularly
useful,
but
to
me,
but
it
looks
really
cool
I,
don't
know,
maybe
I
just
I,
don't
know
I
mean
maybe
I'm
more
of
a
text
person
but
yeah.
It
is
cool.
So
personally,
I
prefer
to
use
a
little
command-line
tool.
A
That's
available
on
NPM,
as
web
pack
bundle
size
analyzer.
So
the
way
that
works
is
you
basically,
instead
of
just
doing
web
pack,
you
do
web
pack
Jason
and
then
pipe
that
into
the
size
analyzer,
and
it
will
basically
give
you
a
list
of
all
of
your
dependencies.
You
know
what
percentage
of
the
bundle
they
are
and
all
their
sub
dependency.
So
that's
pretty
cool.
A
So
let's
say
we
run
this
for
our
awesome
bike,
lane
Go
app-
and
this
is
what
it
looks
like
so
you
know
sometimes
it'll
just
show
us
that,
like
one
file
like
moment,
for
example,
might
be
super
huge
and
we
need
to
do
some
work
to
optimize
it.
But
when
we
look
here
we
see
we
have
a
bigger
problem
holy
crap.
It
looks
like
there's
two
versions
of
react,
one
at
the
top
level
and
one
in
this
like
react.
Instinct
plugin.
You
know
what
the
heck
is
going
on,
so
we
see
that
we
have
duplicates.
A
Let's
verify
this
with
NPM,
we
can
use
the
NPM
LS
command,
which
can
either
print
out
your
entire
dependency
tree
like
this,
or
in
our
case
we
want.
We
know
react
is
the
issue,
so
we're
going
to
target
react
specifically,
so
sure
enough.
We've
got
two
versions
of
react,
one
at
15,
15.3
and
one
at
14.8.
So
this
is
the
point
where
you
might
do
something
like
this.
You
know
sigh
and
disdain
tweet
about
how
web
pack
or
NPM
or
react
sucks,
or
you
know,
team
instincts
sucks
for
making
this
package.
A
A
But
don't
worry
don't
do
that.
Okay,
keep
calm.
We
can
deal
with
this
okay.
So
let's
ask
the
question:
why
do
duplicates
happen?
So
what
I'm
going
to
show
you
is
based
off
of
n
PM's,
excellent
documentation,
I
think
it's
right,
but
I'm,
not
an
NPM
expert
employees.
So
you
should
ask
them
if
you
want
further
clarification.
But
let's
do
this:
let's
do
this
all
right,
so
it
used
to
be
an
NPM
to
that
with
we
had
three
dependencies
say
mystic,
valor
and
instinct,
and
they
all
require
the
same
version
of
Pokemon
package.
A
So,
however,
if
mystic
and
valor
installed
Pokemon
too
and
as
usual,
it
goes
to
the
top
of
the
tree,
but
instinct
needs
Pokemon
one.
It
will
be
installed
as
a
sub
dependency
of
instinct,
just
like
npm
to
used
to
work.
Okay,
like
that,
so
sometimes
this
can
still
happen
for
a
lot
of
reasons.
One
of
them
is,
if
say,
we
have
different
ranges
in
stem
verb.
A
So
in
this
case
some
of
our
dependencies
require
any
minor
version
of
version
2,
but
instinct
requires
any
minor
version
of
to
or
greater
than
2
or
greater
greater
than
or
equal
to
1.
So
we
end
up
with
two
versions
of
Pokemon,
even
though
technically
we
could
have
one
and
that's
sad
because
we
don't
want
that.
So
if
this
happens,
npm
has
a
tool
to
fix
this.
So
as
long
as
the
package
summer,
ranges
are
compatible
and
cam
will
be
able
to
de
doop
them.
So
try
this
first
before
you
do
anything
else.
A
Unfortunately,
when
we
run
npm
dee
doop
in
our
package,
this
is
not
fix
our
problem
and
upon
closer
inspection,
we
can
see
that
the
author
of
react
instinct.
You
know
this
team
instinct
person
defined
a
specific
version
of
react
that
is
not
compatible
with
our
version
of
react,
even
though
the
package
should
work
fine
with
15
like
dot
sucks.
So
I
just
want
to
talk
for
a
second
about
versioning,
for
something
like
a
react:
plugin
mainly
for
front-end
consumption,
while
locking
your
dependencies
is
generally
a
good
idea.
A
You
know
as
a
consumer
of
NPM
packages,
because
it
makes
your
build
more
predictable.
If
you're
writing
a
plug-in,
you
probably
want
to
declare
a
range
of
versions
for
what
your
plug-in
is
compatible.
So
don't
lock
it
to
that
one
version
because
you're
going
to
get
duplication,
yeah
so
I
know
this
makes
testing
more
complicated,
but
it's
kind
of
necessary
to
prevent
you
know
bad
things
from
happening.
So
in
the
react
community,
a
lot
of
people
are
using
something
called
peer
dependencies
which
is
kind
of
controversial.
A
So
if
you
want
to
know
more
about
that,
probably
ask
the
MPN
folks,
you
know-
or
oh
that
was
a
mood
cheese.
I
didn't
know
that
was
such
a
sore
topic.
I
mean
go
and
read
some
issues
and
get
context
or
anyways
so
moving
on,
so
we
have
two
incompatible
versions
of
react
to
find
because
team
is
sync
screwed
up
and
fine.
You
know
a
fixed
version
for
zero
point
14
package.
We
really
want
to
make
this
work.
We
really
want
this.
A
So
at
this
point
we
have
a
couple
of
options
to
hack
things
up
on
the
web
pack
side
and
I.
Personally
am
a
huge
fan
of
hacks,
so
I'm,
sorry,
if
you're,
not
one
thing
we
could
do
is
override
the
resolve
configuration
option
to
web
pack
so
that
anytime
react
is
called
by
a
module
or
its
dependencies.
Web
pack
will
always
resolve
to
your
top-level
react
package
yeah.
This
is
totally
a
hack
and
it's
you
know
outside
of
NPM,
but
it
does
work.
So
if
you
have
no
other
options,
try
it
on.
A
A
Another
thing
you
can
do
to
reduce
duplication
is
to
use
web
packs,
built-in
optimized
edu
plug-in,
which
will
actually
search
the
tree
for
duplicate
files
at
compile
time
and
then
take
them
out.
So
I
highly
recommend
this
to
so
after
resolving
duplicates
and
applying
web
packs
optimizations.
Our
bundle
is
now
at
136
k,
that's
like
600
or
something
k
saved.
You
know
thanks
to
a
little
bit
of
sleuthing.
A
A
So
we
build
a
lot
of
this
with
modern
web
tech,
but
we
still
have
to
build.
Ap
is
in
the
context,
I
know
in
the
constraints
of
Firefox
itself,
which
is
you
know
of
20
year
old
or
so
code
base
and
I've
been
thinking
about
how
we
can
incrementally
do
things
better
and
I
have
to
say
that
using
external
dependencies
is
definitely
the
top
of
my
list.
A
So
if
you
do
work
in
a
legacy
code
base
who
works
in
a
legacy
code,
base
least
some
of
the
time
yeah
most
of
us
I
mean
we're-
probably
mostly
spoiled
here,
but
a
lot
of
people
have
to
do
that,
and
you
know
you
probably
have
some
way
of
making
things
work.
A
lot
of
people
have
like
a
vendor
folder
that
gets
checked
into
the
repo
that
you
manually
update
and
it
kind
of
sucks.
So,
let's
see,
if
you
know
we
can
make
that
better.
A
So
remember
this
yeah
awesome,
so
it
sucks
for
a
lot
of
reasons,
but
this
is
like
a
way
of
loading
modules.
Okay,
so
maybe
you
have
upgraded
a
bit
and
you
concatenated
those
files
in
a
single
bundle.
That's
cool!
That's
cooler!
I'm!
In
Firefox,
we
actually
have
a
few
different
custom
module
loading
systems,
so
you
might
have
that
too.
We
even
have
an
implementation
of
common
JFS
that
we
can
use
with
the
add-on
SDK.
So
it's
pretty
good,
but
it
unfortunately
doesn't
integrate
with
NPM.
So
we
still
need
to
figure
that
part
out.
A
So
one
thing
to
keep
in
mind
when
you're
working
on
integrating
new
systems
into
a
legacy,
one
don't
try
to
rewrite
the
whole
thing
at
once.
Just
don't-
and
you
know-
maybe
you
maybe
you
could,
but
firefox
is
millions
of
lines
of
code.
So
it's
pretty
much
out
of
the
question
for
us
yeah.
So
instead
consider
writing
a
proxy
for
your
module
loader
of
choice,
so
you
can
start
including
external
dependencies
without
having
to
take
the
whole
system
down.
So
it's
all
again.
A
This
is
a
bit
of
a
hack,
but
if
you
write
a
proxy
to
import
modules
from
mpm
and
then
use
web
pack
or
another
module
loader
of
choice
to
transform
that
into
a
compatible
interface
with
your
legacy
system,
you
get
all
the
benefits
of
being
able
to
install
and
track
external
dependencies
without
having
to
change
the
way
your
system
loads
modules.
So
let's
see
what
that
looks
like
in
our
Firefox
project,
so
first
we
create
a
file
called
vendor
jas
and
we
simply
export
each
external
dependency.
A
We
want
to
take
advantage
of
in
the
old
system
all
right,
so
then
the
web
pack
side.
We
can
use
a
couple
of
settings
in
the
configuration
object,
so
in
this
case
we're
specifying
a
library
target
bar,
which
means
it
outputs,
a
global
variable
and
we're
naming
the
variable
vendor.
So
in
your
legacy
fell.
All
you
need
to
do
is
include
that
script.
A
So
the
output
of
the
bundle
in
a
script
tag,
and
then
you
just
do
window
vendor
avocado
or
dot
pokemon
or
whatever
else,
dot
wombat
in
our
Firefox
project,
we're
actually
going
to
use
the
commonjs
library
target,
which
actually
means
that
pack
outputs
a
bundle
that
exports
the
compiled
result
of
all
our
dependencies.
So
this
is
really
useful.
If
you
have,
you
know
commonjs
system,
but
it's
not
compatible
with
NPM.
A
So
in
a
Firefox
code,
all
we
need
to
do
now
is
require
the
vendor
bundle
and
then
get
avocado
from
that
boom.
We
have
access
to
NPM,
awesome
right,
so
Firefox
and
still
be
Firefox,
and
we
have
external
dependencies
yay.
So
obviously,
there's
a
lot
more
work
to
be
done
here,
but
focusing
on
what
we
really
need
and
then
making
some
compromises
allows
us
to
have
better
things.
A
So
you
know,
I've
talked
a
little
bit
about
analyzing
your
tree
about
D
duplicating
but
using
webpack
to
make
happen,
but
what
it
looks
like
to
add
NPM
into
a
legacy
code
base
and
there's
a
lot
of
things
that
community
has
discovered
to
make
front
end.
Dev
I'm
can
better
as
well
as
planning
by
NPM
to
make
sure
it
continues
to
improve.
So
that's
awesome,
but
I
think
the
most
important
thing
to
remember
is
that
mpm
serves
a
very
diverse
set
of
use
cases
which
is
both
extremely
hard
and
extremely
awesome.