►
From YouTube: The Path to ES Modules by Bradley Meck, GoDaddy
Description
The Path to ES Modules - Bradley Meck, GoDaddy
Discussing the process taken in creating interoperability between ES modules and existing node modules. This covers the history of the interoperability proposal as well as some lessons on what ES modules are. We will be discussing largely the how and why of the proposal, not the exact implementation of proposal. Discussion will take an approach of the process, and walk through how the process worked out in one of the first major EP since the creation of a standard way to discuss disruptive changes to node's core. This is a major ecosystem change and is targeted towards a general audience since discussion of the effects of the change on all involved parties affects almost everyone.
About Bradley Meck
Employed at NodeSource, Bradley likes to work on tooling for Node.js and is actively seeking to improve debugging and analysis tools for programs.
A
Okay,
so
this
talk
is
gonna,
be
mostly
a
history
lesson
about
how
we
got
to
the
location.
We
are
today
with
es
modules
and
talking
a
little
bit
about
standards,
bodies
and
my
social
interactions
getting
here.
So
a
brief
bit
about
my
history,
I
started
using
node
when
it
wasn't
even
0.2
I've
been
involved
in
the
community
since
then,
but
I've
always
been
interested
in
having
new
features
for
modules.
A
If
you've
ever
heard
about
es
4,
it
is
a
completely
different
language
from
JavaScript,
as
we
know
today
had
a
lot
of
very
interesting
ideas
that
had
a
type
system.
It
also
had
this
thing
called
packages,
and
there
are
two
entire
paragraphs
in
the
spec
for
es
4
about
what
a
packages
and
it's
going
to
be
similar
to
what
we
consider
a
jar
archive
for
what
a
package
is,
but
it's
all
in
the
same
source
file,
so
it
would
be
under
the
same
dot.
A
A
Around
2008
tc39
decides
to
scrappy
s4,
it's
just
too
hard
to
implement
too
complex,
and
essentially
it's
too
big
of
a
change.
But
the
important
thing
here
is
it
had
a
concept
of
packages
and
the
concept
of
namespaces
doesn't
really
talk
about
modules
and
these
things
were
drastically
different
from
what
No
thinks
of
its
modules.
And
so,
as
this
gets
scrapped,
we
move
on
and
people
still
need
modules.
A
They
need
some
way
to
be
able
to
load
multiple
files
and
have
them
coordinate
their
variables,
and
so
Mozilla
comes
along
in
2009
and
it
actually
works
with
some
members
of
tc39
and
creates
the
common
jeaious
module
specification
which
strictly
exports
dictionary
objects.
So
what
we
think
of
as
object
literals
with
you
know,
string
properties
as
their
keys
and
whatever
value
you
want
at
that
string
property.
A
Much
like
we
were
talking
about
with
node
modules.
In
a
bit,
any
implementation
of
common
JS
modules
uses
a
function
to
wrap
any
given
source
text.
So
if
you
have
a
dot
JS
file,
it
changes
from
what
browsers
historically
have
seen.
Is
this
script
file
that
runs
at
the
top
level
to
a
function
body
and
that
doesn't
really
sound
like
much,
but
it
changes
parts
of
the
grammar
parts
of
what
you
can
do
like.
A
Suddenly,
we
have
a
concept
of
early
return,
so
if
you've
ever
had
I,
don't
know
if
process
env
debug
returned
because
you
don't
want
your
module
to
load
if
you're
in
a
debug
mode.
This
is
the
first
time
we
start
to
see
something
like
that
and
much
like
what
es
modules
will
be.
The
loader
is
entirely
left
up
to
the
environment.
A
It's
left
up
to
node
a
browser
CouchDB
ringo
anything
to
implement
the
loader,
which
is
what
takes
the
files
on
disk,
determines
what
type
of
file
they
are
and
actually
puts
it
into
the
VM,
and
so
this
actually
gains
a
fair
bit
of
traction.
It's
the
first
real
module,
loader,
that's
adopted
by
multiple
projects
that
are
or
become
popular,
we're
at
a
node
conference.
So
you
can
assume
no,
it
picks
it
up.
There's
also
another
project
called
Ringo
Jas
and
that's
using
Java,
and
it
is
strictly
adhering
to
common
jeaious.
A
It
doesn't
have
a
lot
of
the
differing
features
that
node
has
and
interestingly
couchdb
has
a
common
jazz,
loader
embedded
inside
of
that
so
yeah.
So
with
2009
we
get
common
J's
modules,
a
quick
follow
when
node
is
released
towards
the
end
of
2009.
We
start
to
see
nodes
implementation
of
common
J's,
so
common
J's
doesn't
really
specify
anything
about
path
semantics.
So
what
I'm
talking
about
path?
A
Semantics
I'm
talking
about
file
paths,
what
the
file
extensions
do
if
you
search
for
different
file,
extensions
or
even
how
node
modules
works
at
all
the
prevailing
assumption
up
until
this
point
is
that
when
you
load
a
path,
there
is
one
and
only
one
resource
that
can
live
at
that
path.
Node
changes
this.
It
starts
to
search
the
file
path
like
a
path
variable
for
your
environment.
A
It
starts
looking
for
things
in
you,
know:
dot,
JS
files
versus
dot,
JSON
files,
and
this
is
the
first
time
where
we
start
to
diverge
from
having
one-to-one
mappings
of
paths
to
having
multiple
resources
potentially
imported
by
the
same
string.
It's
also
the
main
time
where
we
have
this
idea
of
a
single
value
of
export.
When
we
were
talking
about
common
J's
earlier
we're
talking
about
a
dictionary
object,
it's
always
an
object
and
it
always
has
string
properties
declared
for
what
you
can
import.
A
Node
took
a
different
approach
here.
It
said
whatever
is
that
module
dot?
Exports
is
the
value
for
the
entire
module,
so
we're
no
longer
limited
to
just
generating
a
single
object.
We
can
have
an
export
of
that
is
a
function.
So
if
you
require
request,
for
example,
off
NPM,
we
can
use
it
as
a
function.
It's
not
strictly
an
object,
so
we
don't
have
to
do,
require
requests
that
requests
or
anything
like
that,
and
we
introduce
a
few
special
context
variables.
At
the
same
time,
requirejs
shows
up
so
in
terms
of
age,
AMD
and
node.
A
Common
jeaious
are
actually
pretty
similar.
It's
very
hard
to
determine,
which
showed
up
first
required.
Jeaious
was
made
from
lessons
learned
on
the
browser
side
of
things,
so
it
has
different
priorities.
It
it's
going
and
taking
everything
needs
to
be
asynchronous.
Things
need
to
be
loaded
in
parallel,
but
it
shares
some
commonalities
with
common
jason
node.
It
has
single
value
exports
like
node.
Does
it
doesn't
follow
the
common
2's
dictionary
path?
A
It
wraps
any
given
source
text
in
a
function
and
when
you're
using
it,
it
feels
a
little
bit
interesting.
It's
something
that
no
tried
to
implement
for
a
while
with
require
dot,
async
and
it
never
really
took
off.
There
were
some
complexities
of
it
and
there
was
a
lot
of
verbosity
but
unfortunately
required.
Aijs
doesn't
really
have
a
specification.
It
has
some
documentation
on
how
require
digest
works,
but
it's
what
it
is.
A
There's
no
standards
body
behind
it,
there's
not
a
team
of
people
trying
to
define
the
behavior
or
edge
cases,
and
it
actually
goes
and
calls
out
command
jeaious
in
its
description
of
itself,
and
it
basically
states
that
command
just
didn't
work
in
the
browser.
So
we
had
to
make
something
new
among
those
new
things
that
we're
gonna
start
seeing
at
this
point
is
NPM
shows
up
the
next
year
in
2010,
so
we
were
talked
about.
A
There
were
multiple
paths
that
could
have
multiple
resources,
backing
them,
so
MPM
shows
up
and
we
start
to
see
node
modules
directory
x'.
So
we
start
seeing
people
installed
modules,
just
using
a
tool
put
it
in
a
directory
and
suddenly
it
works.
You
can
update
your
directory
and
it'll
keep
working.
A
This
eventually
lands
in
node,
and
it's
interesting
just
because
this
changed
two
nodes.
Documentation
and
specification
came
from
user
land,
and
this
is
something
that
I
want
to
stress,
especially
with
standards
bodies,
it's
very
uncommon
to
my
knowledge
for
user
land
to
land
exactly
into
spec.
Usually
it's
the
other
way
around
where
spec
mandates
what
happens
in
user
land.
In
my
experience,
because
specifications
go
through
weird
edge
cases,
they
go
through
problems
with
grammar
and
they
just
discuss
all
sorts
of
stuff.
A
All
sorts
of
things
that
the
average
programmer
will
probably
never
see
yeah
and
so
at
this
point,
tc39
starts
writing
what
we
are
going
to
call
es
module
since
what
what's
eventually
going
to
become
the
standard
that
we're
going
to
be
seeing
in
the
future
and
browsers
and
in
node
it
has
completely
new
semantics
everything
we've
talked
about
up
until
this
point
uses
some
sort
of
value:
semantics,
meaning
when
you're
sharing
something
you're
sharing
a
value.
It's
it's
almost
like
a
copy
operation,
yes
modules.
A
They
share
variables.
So,
when
I'm
going
and
trying
to
import
or
export
something,
I'm
telling
you
that
this
variable
is
available
to
be
imported
into
another
scope.
I'm
not
saying
the
value
is
so
if
I
change
the
value
at
that
variable,
it
gets
updated
every
where
that
is
in
scope.
So
that's
something
that
is
not
visible
in
any
of
the
other
specifications
up
to
this
point,
and
it's
also
interesting
because
it
introduces
a
new
top
level
parser
to
the
JavaScript
language.
I
don't
have
a
good
example
of
any
other
language
that
does
this.
A
So
there's
some
interesting
things
here
that
we're
gonna
touch
on
in
a
bit.
So
after
tc39
starts
writing
up
all
of
this
Isaac,
the
Isaac
Schluter,
the
guy,
who
wrote
em,
PM's
command
line
and
currently
in
charge
of
NPM
Inc
wrote
this
pretty
good
blog
post
about.
There
are
some
problems
with
how
ES
modules
look.
A
A
They
don't
they
don't
have
too
much
publicly
on
this.
There
are
notes
for
any
tc39
meeting.
No,
it
isn't
really
brought
up
in
the
meeting
notes.
So
most
of
these
discussions
are
kind
of
lost
and
I
don't
have
any
way
to
recover
them,
but
there's
disagreement
on
whether
things
are
about
use
cases,
which
is
how
I
feel
or
whether
they
were
seeking
for
full
compatibility,
which
is
how
some
people
feel
when
discussing
this
point
about
tc39
going
and
changing
the
spec.
A
We
were
talking
briefly
about
how
common
J's
is
value
based.
Nes
modules
are
binding
or
variable
based,
so
there's
a
problem
here.
It's
not
spec
compliant
in
part,
because
the
parser
in
babel
to
this
day
is
not
spec
compliant.
It
has
imports
in
places
that
shouldn't
according
to
the
grammar
and
the
semantics,
are
falling
back
to
nodes
implementation.
Node
uses
a
different
type
of
import
and
export
system.
It
has
a
different
cache
mechanism.
It
has
a
different
way
of
determining
what
a
module
is
and
what
is
a
script.
A
So
six-to-five
is
something
that's
really
interesting
gets
people
excited,
but
then
you
go
and
you
look
back
on
it
and
the
author
of
Babel
basically
agrees
interrupts
between
common
jeaious
nodes,
common
chests
in
this
point
and
ES
modules
is
a
massive
rabbit
hole
of
problems
so
the
next
year,
things
start
heating
up
for
tc39,
they're,
gonna,
land,
yes
modules,
and
so
they
actually
have
this
entire
loader
spec.
That's
built
on
this
asynchronous
registry
and
cache
mechanism.
It
looks
a
lot
like
what
AMD
is,
but
they
can't
get
it
to
work
with
node,
it's
very
complex.
A
They
leave
it
up
to
the
host
environment,
just
like
calm
and
jazz
did
in
the
past
and
so
they've
removed
it
from
the
spec.
Node
has
a
little
bit
of
participation
with
tc39
once
again.
There's
nothing
really
pertinent
in
the
meeting
notes
about
this
and
Babel
is
mentioned
as
an
implementation,
and
one
of
the
reasons
that
it
can
be
thought
of
as
being
done.
A
At
the
same
time,
the
browser's
are
shipping
a
completely
new
loader
spec,
completely
unrelated
to
what
was
originally
in
TC
39
s,
yes,
module
spec,
and
this
is
what
they're
going
to
ship
in
the
future
so
that
whole
talk.
We
had
about
having
a
loader
spec
pulled
out
of
the
es
modules
and
the
JavaScript
specification.
It's
pretty
much
gone.
We're
gonna
have
some
different
stuff,
so
I
eventually
write
enhancement
proposal
for
node.
A
The
new
governance
is
really
nice,
makes
it
easy.
I
can
say
things
we
can
support
it.
If
VMs
gives
us
these
hooks,
it
isn't
strictly
spec
breaking
to
implement
it,
but
it's
a
big
change
for
a
VM
to
be
able
to
support
what
we
plan
out
and
we're
planning
basically
to
have
100%
Interop
with
babel
and
our
idea
to
determine
if
it's
a
module
or
script
comes
down
to
double
parsing.
This
is
a
PR
with
676
comments,
not
including
the
issue
threads
leading
up
to
this
PR.
A
This
PR
probably
took
six
months
of
my
life
away
from
me
in
the
common
threads,
so
I
ended
up
going
and
rewriting
it
after
a
bunch
of
feedback,
and
so
we
start
talking
well,
let's
use
a
file
extension
because
there's
some
problems
and
potential
ambiguities.
If
we
use
parsing
and
if
you've
got
ambiguity,
that's
no
good.
A
So
we
start
using
talking
about
using
a
new
file
extension.
We
remove
problematic
features
of
common
J's
from
what
we
will
support
for
es
modules,
which
means
breaking
some
stuff
from
Babel
at
this
point,
and
the
ctc
for
node
accepts
this
as
the
draft
so
I'm
running
low
on
time,
but
their
Twitter
flame
wars
for
around
two
months
after
this,
it's
just
terrible.
A
A
So
we
need
to
either
change
the
specification
or
use
a
different
expectation
for
developers
on
how
es
modules
are
going
to
work,
and
that
means
we
either
have
this
spec
change
or
we
potentially
break
people
using
babel,
which
is
a
lot
of
people.
So
that's
not
good
because
we
value
the
people
in
the
ecosystem.
That's
on
NPM,
so
Go
Daddy
goes
and
buys
at
tc39
seat
and
we
go
in
July
and
talk
about
changing
the
specification.
A
Currently,
this
is
where
we
are
at
right
now
we
went
and
had
the
tc39
meeting
in
September
to
discuss
the
problems
holding
node
from
implementing
stuff,
there's
some
agreement
that
we
should
loosen
the
constraints
of
ES
modules,
but
we
still
have
pending
issues
even
earlier
this
morning.
We're
talking,
there's
a
tc39
meeting
going
on
at
the
same
time
as
this
conference.
So
it's
a
little
awkward,
but
that's
where
we
are
so
that's
the
history.