►
From YouTube: Keynote: The Future of JavaScript is Universal - Myles Borins, Developer Advocate, Google
Description
Keynote: The Future of JavaScript is Universal - Myles Borins, Developer Advocate, Google
Speakers: Myles Borins
A
I'm
beyond
excited
that
we
have
Robin
joining
us
at
the
foundation
as
our
executive
director,
yeah
I'll
gush
to
all
of
you
about
it
separately.
I
won't
use
my
stage
time
too
much
on
it,
but
one
more
quick
round
of
applause
in
the
back
of
the
room.
You
can
see
a
bunch
of
people
who
are,
you
know,
heads
down
on
computers
and
there's
a
whole
bunch
of
people
back
there.
You
also
can't
see,
but
just
a
quick
round,
applause
for
all
the
people
making
this
happen,
who
you
don't
actually
get
to
see.
A
So
we're
going
to
talk
today
about
universal
JavaScript
and
a
vision
I
personally
have
and
we'll
just
start
with
saying
hello,
Bonjour.
Oh
this
is
a
cat
I
really
like
this.
That's
all
my
name
is
Myles
and
I'm.
A
developer
advocate
at
Google
focused
on
the
node.js
ecosystem
and
Google
cloud
platform.
You
know
I
always
put
this
at
the
bottom
of
this
slide.
Just
saying
hey,
this
is
my
own
opinions,
so
you
know
it
take
it
or
leave
it,
but
I'll.
Take
it
a
step
further.
A
A
This
was
what
many
of
you
may
be
thinking
right
now,
cuz
without
any
context,
I'd
say
it's
meaningless.
Universal
means
different
things
to
different
people.
You
can
get
an
idea
of
the
positive
response,
I'm
getting
here,
someone
playing
buzzword,
bingo,
so
that's
always
fun,
1998
called
and
once
it's
optimism
back
and
this
actually
came
in
two
separate
forms
from
two
separate
people.
I
think
this
is,
you
could
say
the
same
thing
in
a
different
way.
It
was
such
a
hype
idea.
A
decade
ago,
I
even
got
quotes.
A
We
did
buy
a
horse,
Jay
asked
which
made
my
whole
week.
I
love
it
when
that
happens,
but
some
people
in
my
personal
opinion,
just
got
it
like
they.
They
have
that
same
vision,
code
just
works
in
the
browser,
a
note
and
I
don't
have
to
think
very
hard,
no
build
step
necessary
across
both
the
web
and
node,
not
having
to
transpile
code
to
multiple
targets,
write
once
run
everywhere.
This
is
great
I'm
hiring
this
person
to
do
marketing.
A
For
me,
this
is
very
succinct,
very
to-the-point
and
you
may
be
asking
yourself:
is
this
different
than
isomorphic
JavaScript?
And
the
answer
is
clearly
yes,
and
this
is
going
to
talk
about
isomorphic
JavaScript,
so
I'm
not
gonna,
get
too
much
into
it,
but
isomorphic
JavaScript
is
a
term
that
actually
it
was
created
in
2011.
A
So
when
people
were
saying,
oh,
you
have
the
optimism
of
a
decade
ago,
they're,
not
exaggerating,
and
and
this
blog
post
written
by
Charlie
Robbins,
who
is
a
board
member
of
the
open,
J's
Foundation,
potentially
somewhere
in
this
room,
coined
the
term
isomorphic
JavaScript,
and
you
can
find
this
from
the
wayback
machine.
You.
If
you're
reading
the
small
text,
which
you
probably
can't
you'll
notice
that
it
does
talk
about
the
idea
of
running
JavaScript,
both
on
the
client
and
the
server.
But
one
of
the
things
that
was
fundamentally
different
about
the
concept
of
isomorphic
JavaScript.
A
It
was
heavily
heavily
tied
to
the
concept
of
the
view
and
and
Model
View
controller
and
which
patterns
of
designing
single
page
applications
could
be
run
on
the
server
for
server-side
rendering
you
know
nine
years
ago.
It
was
just
as
hard
as
today,
maybe
a
little
harder
to
serve
a
site
that
was
primarily
JavaScript
and
actually
have
any
sort
of
machine.
A
Like
know
what
it's
doing
without
running
the
code,
and
it
also
creates
like
a
really
slow
time
to
first
paint-
and
this
talk
is
not
about
any
of
those
things
and
I
would
argue
that
universal
JavaScript
is
while
it's
similar
to
morphic.
Javascript
is
a
fundamentally
different
thing
and
we'll
dig
into
that
a
bit,
but
universal
JavaScript
and
its
new
tagline
runs
once
run
anywhere
and
I
bet.
All
of
you
are
now
thinking.
Universal
JavaScript
is
great
and
you
want
me
to
actually
tell
you
about
it.
A
So
I'm
going
to
the
first
thing,
that's
important
about
the
concept
of
universal
JavaScript
and
running
everywhere
is
thinking
about
all
the
places
you
may
want
to
actually
run
your
code.
So
obviously,
we've
got
browsers
and
node.
We've
already
mentioned
that,
but
there's
a
lot
of
other
places
where
you
might
be
running
JavaScript
as
well.
Demo
is
a
fantastic
new
platform
that
Ryan
Dahl.
The
creator
of
node
has
come
up
with,
has
some
different
concepts
and
different
thoughts
about
how
JavaScript
would
work
different
api's.
A
We
have
edge
workers
a
great
product
from
CloudFlare
that
is
running
javascript
on
the
edge
of
a
CDN.
It's
API
is
designed
heavily
after
the
serviceworker
api.
It
has
fetch,
but
it's
kind
of
its
own
subset.
It's
its
own
run
time.
It
has
its
own
opinions
about
how
to
run
execute
and
debug.
Javascript
moddable
is
a
really
cool
one
for
embedded
systems.
It's
a
version
of
JavaScript
that
you
can
run
on
tiny
chips
and
put
anywhere
moddable
implements
their
own
API.
Is
they
also
implement
the
entire
language
itself?
A
As
far
as
I
know,
moddable
actually
already
influenced
top-level
await
and
is
one
of
the
most
compliant
JavaScript
engines
out
there.
It's
actually
probably
a
good
time
to
stop
for
a
second
and
say
that
all
of
the
the
ones
above
aside
from
browsers
a
lot
of
those
are
using
v8.
The
javascript
engine
from
chrome
model
is
not
it's
using
its
own
JavaScript
engine
that
they
manage
themselves
and
we'll
see.
We
see
a
lot
of
other
places
where
javascript
is
showing
up
as
well
embedded
inside
of
databases.
A
You
can
also
see
it
inside
of
productivity
software,
all
sorts
of
ways
of
scripting
things
and
automating
things
in
ways
you
wouldn't
have
imagined
and
JavaScript
is
showing
up
all
over
the
place
and
to
me
this
is
one
of
the
reasons
why
Universal
javascript
is
so
important
when
we're
writing
our
libraries
or
we're
writing
our
productivity
tools
or
we're
moving
between
these
different
environments.
We
don't
necessarily
know
where
the
code
we're
writing
is
going
to
end
up.
A
We
don't
even
know
who's
going
to
use
it
so
kind
of
starting
from
this
principle
of
a
baseline
that
can
be
share.
It
everywhere
make
sure
that
your
codes
extensible
make
sure
it
can
be
shared
in
different
places.
All
of
these
environments
share
parts.
There
are
not
these
fundamentally
different
things.
We
have
standards,
we
align
along
a
baseline
and
the
the
core
of
all
of
that
is
equi
to
6
2,
which
is
specified
by
tc39
the
standards
organization
that
specifies
the
JavaScript
language
and
within
Etna
2
6
2.
A
If
you
look
into
the
spec
there's
a
couple
concepts
that
I
won't
get
too
much
into
right
now
of
realms
intrinsics
and
primordial
x',
and
this
is
like
the
soup
that
makes
up
the
core
of
JavaScript
realms,
are
the
context
where
your
code
runs
I'm
glossing
over
it,
but
find
me
later
for
more
details.
Intrinsics
are
all
the
different
built-ins
that
are
available
on
the
global
object
that
you
can
change
and
you
can
use
and
primordial
are
the
ones
that
are
necessary
to
even
bootstrap
the
environment.
A
A
These
API
s
are
all
available
in
every
single
JavaScript
runtime.
These
are
all
standardized
by
equi
6,
but
they
serve
slightly
different
purposes.
Something
like
JSON
or
math
or
date
are
almost
more
like
libraries
within
JavaScript,
whereas
things
like
object,
our
core
capabilities,
one
of
the
cool
things
about
these-
these
are
all
intrinsic
node-
has
done
some
work
recently
and
freezing
all
of
these
objects,
because
you
don't
want
some
random
module,
changing
the
way
that
node
does
things
internally.
A
This
is
an
example
of
a
way
that
a
platform
can
do
small
changes
to
the
way
it
works
above
the
baseline
runtime,
without
really
causing
major
differences
for
people.
But
one
of
the
things
that
tc39
specified
you
know
in
the
recent
future
of
5
years
ago
was
es
modules
and
prior
to
es
modules.
There
was
no
common
way
to
share
code
between
all
of
these
different
environments.
A
If
you
wanted
to
take
one
piece
of
code
and
link
it
to
another
piece
of
code,
you
are
either
literally
concatenating
the
files
together
or
running
a
tool
such
as
Babel
or
roll-up
or
web
pack
to
pack
everything
together,
so
you
could
run
it.
Node
was
one
of
the
few
environments
that
had
a
built
in
module
system,
which
was
common
j/s,
which
is
what
a
lot
of
other
runtimes
copied,
but
it
was
not
standardized
and
it
wasn't.
Common
jeaious
itself
wasn't
built
in
a
way
that
browsers
could
use
as
well.
A
Yes,
modules
made
some
compromises,
didn't
make
everyone
happy,
but
was
something
that
all
of
these
different
environments
can
share
and
I
would
like
to
push
it
a
step
further
and
say
that
modules
have
been
the
missing
piece
to
really
enable
universal
JavaScript
without
modules.
As
kind
of
this
shared
way
of
sharing
code,
we
were
destined
to
have
to
transpile.
A
We
had
to
do
some
sort
of
function
on
the
code
in
order
to
use
it
in
different
places,
but
that's
where
things
get
kind
of
weird,
because
even
though
es
modules
are
specified
in
Ethne,
the
loader
itself
is
not
the
loaders
implemented
by
the
embedder.
So
in
node.js
we
implement
the
loader
and
the
chromium
browser
blink
implements.
The
loader
and
tc39
also
leaves
it
up
to
the
hosting
environment
to
determine
resolution.
How
do
we
take
that
string
that
you
give
that
says?
A
Hey
I
want
this
thing
and
find
it
it's
up
to
the
runtime
to
turn
a
reference
into
a
location,
to
fetch
a
resource
from
that
location,
to
do
this
recursively
and
build
a
graph
and
give
the
engine
the
entire
graph
to
execute
this
core
piece
of
shared
infrastructure,
which
is
standardized.
Has
this
single
place
where
every
single
runtime
can
make
their
own
decisions
in
bv8
this
single
place,
where
you're
actually
saying
hey?
Here's
the
code
I'm
sharing.
A
This
is
one
of
the
reasons
that,
in
the
ESM
implementation
of
node
were
pushing
towards
removing
some
of
the
magic
from
common
j/s.
That
browsers
will
that
won't
be
capable
in
the
browsers.
This
is
a
potential
place
of
platform,
divergence
and
platform.
Divergence
is
something
that
gives
me
existential
dread
and
a
known
side
effect
about
existential
dread
is
that
it
causes
nihilistic
transpilation.
A
This
is
a
term
I
coined
myself
recently
nihilistic
transpilation
is
when
you
have
so
given
up
on
the
concept
of
universal
MA
JavaScript,
where
you've
so
bought
into
the
fact
that
we're
always
going
to
need
to
build
we're,
always
going
to
need
to
transpile
that
universal
JavaScript
doesn't
even
matter
anymore.
It's
not
a
priority,
it's
not
a
thing
that
needs
to
be
thought
about.
It's
just
not
possible.
A
We
may
as
well
just
you
know,
accept
our
transporation
gods
and
move
forward,
and
it's
built
on
this
idea
in
my
personal
opinion
that
javascript
platforms
are
potentially
fundamentally
different.
I
would
say
that
they're
not
fundamentally
different,
but
they
can
have
drastically
different
api's,
which
is
fine.
Different
platforms
have
different
needs.
That
doesn't
mean
that
the
core
language
needs
to
be
different,
and
people
may
ask
that
question.
Is
the
browser
fundamentally
different
from
nodejs?
And
yes,
it's
api's
are
gonna,
be
fundamentally
different,
but
they
do
come
from
the
same
soup.
A
A
So
if
you
look
at
a
standards
organization
like
what
working
group
you
may
think
to
yourself,
aren't
what
working
group
of
standards
standards
brother
browser-specific,
so
they
standardize
HTML
and
they
standardize
dom
and
those
aren't
things
that
node
does,
although
with
server-side
rendering,
maybe
it
does
I
guess
note
as
a
platform
doesn't,
but
we
do
have
what
working
group
standards
api
is
in
both
run
way.
Runtimes
and
I
have
an
asterisks
there
because
they
differ
a
little
bit
but
we're
trying,
but
something
like
console
or
URL
or
the
encoder
api.
A
These
are
all
things
that
are
standardized
at
what
working
group
that
we
have
in
node
I
think
you'd
be
very
hard-pressed
to
find
a
JavaScript
runtime,
that's
easy
to
use
that
doesn't
have
console
in
it
hat
like
that's
how
I
debug
like,
if
you
don't
have
console
you're
kind
of
like
how
do
you
even
get
started
and
there's
even
other
standards
that
aren't
yet
in
nodejs
that
we're
exploring
I
know
people
say,
stop
trying
to
make
fetch
happen.
I'm
not
gonna.
Stop
trying
to
make
fetch
happen.
A
I
want
such
to
happen,
but
this
is
a
really
great
example
of
one
of
those
ap.
Is
that,
like
on
the
surface
from
an
API
perspective,
most
developers,
like
that's
great
I,
give
a
string
to
a
function,
and
it
gives
me
a
promise
and
then
that
promise
is
gonna.
Give
me
the
thing
that
I
asked
for,
but
under
the
hood
there's
so
many
subtle
differences
between
node
and
the
browser.
A
The
browser
only
really
ever
has
one
tenant
you're
not
worried
about
multiple
people,
making
requests
and
node
the
same
process
may
have
requests
from
10
20
a
hundred
different
people.
You
can't
share
the
state
of
the
fetch
object
in
the
same
way
it
can
create
security
concerns,
but
should
those
plumbing
problems
be
something
that
means
we
don't
have
shared
API
surface?
A
How
am
I
calling
into
that
thing?
Does
it
work
the
way
that
I'm
expecting
it
to
work
and
I?
Think
for
a
world
of
universal
JavaScript?
We
need
to
be
thinking
more
about
the
interface
than
the
plumbing
platforms
can
worry
about
the
plumbing.
As
long
as
the
behavior
is
similar
enough.
If
developers
have
shared
interfaces,
we
can
get
a
lot
done
and
that
Sirsa
ass
kind
of
like
this
question
of
like.
Where
does
the
platform
begin?
We
have
those
intrinsics
and
primordial
zat.
What
point
does
it
become?
The
platform
is
console
part
of
the
platform.
A
Is
it
part
of
the
runtime?
Where
does
the
platform
end?
When
does
it
start
becoming?
The
part
that
is
frameworks
like
these
are.
These
are
a
lot
of
words,
and
maybe
you
know,
maybe
it's
a
little
too
broad,
but
I
think
it's
really
important
to
think
about
these
things.
We're
all
using
these
tools.
What
part
is
the
language?
What
part
is
the
platform?
What
part
of
the
frameworks?
A
Why
do
I
care
about
these
things,
and
where
is
the
code
that
I'm
writing
fitting
into
this
picture,
and
I
want
to
suppose
that
perhaps
Universal
JavaScript
is
a
platform
concern
and
a
great
example
here
is
JSON
modules.
How
many
people
here
have
ever
required
JSON
before
in
node,
you
can
just
require
JSON
and
it
gives
you
an
object
and
it's
a
really
great
experience
in
the
browser.
If
you
want
to
get
JSON
right
now,
you
have
to
fetch
it
which
all
of
a
sudden
introduces
a
promise,
and
it
complicates
things
so
inspired
by
nodejs.
A
Json
modules
were
actually
specified
in
the
HTML
spec
by
what
working
group,
but
it
was
rejected
at
T
PAC
for
security
concerns,
t
pack
being
the
conference
of
w3c
as
a
response
to
this
there's
a
proposal
at
TC
39
working
on
module
attributes
to
try
to
handle
the
security
concerns
that
were
raised
by
the
w3c.
The
reason
that
I
bring
this
all
up
is
that
Universal
needs
to
be
a
platform
ethos.
A
The
idea
that
we
could
have
JSON
modules
and
have
a
shared
interface
for
JSON
modules
across
every
single
runtime
requires
all
of
these
different
partners
in
the
web
ecosystem
to
work
together
for
a
you
know
shared
good,
and
there
are
a
lot
of
these
standards
happening
at
tc39,
we're
exploring
built-in
modules
and
standard
libraries
and
module
attributes.
These
are
all
things
that
will
bring
us
closer
to
a
future
of
of
universal
JavaScript.
A
At
what
working
group
they're
they're,
exploring
JSON
modules
at
the
w3c
they're,
exploring
import
Maps,
which
will
allow
bear
imports
in
the
browser
and
huazi,
which
would
be
a
shared
system
interface
that
can
be
used
across
many
runtimes
with
webassembly,
but
with
all
this
work
happening
in
different
places,
how
do
we
find
a
shared
vision?
And
this
isn't
a
question
that
I
have
an
answer
to
today?
This
is
a
question
that
I
think
we
as
a
group
need
to
be
thinking
about.
Where
do
we
collaborate
when
we
have
all
of
these
disparate
stakeholders?
A
A
Fundamentally
different
I
would
say
that
developers
shouldn't
have
to
know
about
that
beyond
an
API
developer,
skills
should
be
portable
and,
to
me,
that's
one
of
the
most
powerful
things
about
the
concept
of
universal
and
I.
Think
it's
one
of
the
reasons
why
a
platform
like
node
was
so
successful.
Portable
skills
and
I
would
even
go
as
far
as
to
say:
Universal
needs
to
be
a
platform
concern
and
not
a
development
target.
This
needs
to
be
something
that
fundamentally,
we
are
all
working
towards
Universal.