►
From YouTube: Leveling up WebAssembly itself: Going from MVP to brave new world - GitHub Universe 2018
Description
Presented by Lin Clark, Principal Developer Advocate (Mozilla).
We start with the narrative of collaboration with experiential artist Ian Brill who created the ARCH piece and progress into how code can express 3D Space (perhaps 4D if you include time) in computing power. Then we’ll dive into why this structure is a good mental model for how WebAssembly and JavaScript work together through something called linear memory.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
I'm
Lynn,
Clarke
and
I
make
code
cartoons
and
I
also
work
at
Mozilla,
where
I
get
to
tinker
with
things
like
rust
and
web
assembly,
which
I'll
be
talking
about
today
before
I
start
though
I
want
to.
Let
folks
know
that
the
talk
description
is
a
little
different
from
the
talk
I'll
actually
be
giving
today
the
title
was
updated,
but
unfortunately
the
description
was
not,
but
this
one
is
even
better
than
the
one
that
I
have
in
the
program,
so
I
think
you're
gonna
like
it
so
first
off,
one
is
webassembly.
A
Webassembly
is
a
way
of
running
programming
languages
other
than
JavaScript
on
the
web.
Up
until
now,
if
you
wanted
to
do
something
on
a
webpage
like
run
a
calculation
or
change
something
in
the
Dom,
the
only
language
that
you
could
use
was
JavaScript,
but
now
that
there's
webassembly
you
can
use
other
languages
things
like
C
and
C++
and
rust
you
compile
them
to
web
assembly,
and
then
you
can
run
them
on
the
web
page.
Just
like
you
would
JavaScript
now.
I
wish
I
had
time
to
go
into
more
detail
about
this.
A
About
the
basics
of
how
web
assembly
works,
because
it's
pretty
fascinating,
but
unfortunately
this
talk
is
so
jam-packed
with
content
and
with
the
future
that
I
can't
to
talk
too
much
about
what
already
exists.
In
fact,
it's
so
jam-packed
I
can't
even
really
go
into
depth
about
what
is
actually
in
the
talk,
but
I
do
like
going
into
more
depth.
A
So
I'm
gonna
be
posting
a
reading
list
of
links
that
help
with
all
of
this
stuff
soon,
and
the
first
view
in
that
list
are
a
series
that
I
published
when
webassembly
first
started
being
turned
on
by
default
and
browsers
in
March
2017.
You
might
have
actually
seen
this
series
one
thing
that
I've
noticed
and
found
interesting
since
I
started
talking
about
web
assembly
back
then,
is
this
misconception
that
people
have.
A
The
misconception
is
that
the
web
assembly
that
landed
in
browsers
back
in
2017
what
we
called
the
Minimum
Viable
Product,
the
MVP
of
web
assembly
people,
think
that
is
the
final
version
of
web
assembly.
They
think
that
that
is
the
web
assembly
that
we're
going
to
have
all
the
way
into
the
future
and
I
can
understand
where
this
misconception
comes
from,
because
the
webassembly
community
group
is
really
committed
to
backwards
compatibility.
A
So
the
web
assembly
that
you
create
today
will
continue
to
work
in
browsers
into
the
future,
but
that
doesn't
mean
that
its
feature
complete.
That
doesn't
mean
that
it
has
all
of
the
features
that
it's
going
to
have
in
that.
In
fact,
that's
far
from
the
case,
there
are
so
many
features
that
are
coming
to
web
assembly
that
are
going
to
fundamentally
alter
what
you
can
do
with
it.
I
think
of
these
future
features
kind
of
like
the
skill
tree
in
a
video
game.
A
A
The
very
beginning
of
web
assembly
story
starts
with
Emscripten,
which
made
it
possible
to
run
C++
code
on
the
web
by
transpiling
it
to
JavaScript,
and
that
made
it
possible
to
bring
large
existing
C++
code
bases
for
things
like
games
and
desktop
applications
to
the
web,
but
it
turns
out
that
the
j'
acid
automatically
generated
was
still
significantly
slower
when
than
when
it
was
run.
As
native
code.
A
stroke
of
insight
fix
this,
though
one
of
Firefox
says
JavaScript
engineers
figured
out
how
to
make
JavaScript
run
fast.
A
This
JavaScript
run
fast,
and
that
gave
us
a
sanjay
s.
Once
the
other
browser
vendors
saw
how
fast
azzam
JS
could
go,
they
started
adding
the
same
optimizations
to
their
engines,
but
that
wasn't
the
end
of
the
story.
It's
just
the
beginning
of
the
story.
There
were
still
things
that
engines
could
do
to
make
this
faster,
but
they
couldn't
do
it
to
JavaScript
itself.
Instead,
they
needed
a
new
language,
one
that
was
designed
specifically
to
be
compile
and
that
language
is
webassembly.
A
So
what
skills
did
we
need
for
the
first
version
of
web
assembly
to
get
that
minimum
viable
product
that
could
actually
run
c
and
c++
on
the
web?
The
folks
working
on
web
assembly
knew
that
they
didn't
just
want
to
support
C
and
C++.
They
wanted
many
different
languages
to
be
able
to
compile
to
web
assembly,
so
they
needed
a
language
agnostic,
compile
target.
They
needed
something
like
the
assembly
language
that
desktop
applications
are
compiled
to
like
x86,
but
this
assembly
language
wouldn't
be
for
an
actual
physical
machine.
A
It
would
be
for
a
conceptual
machine
and
that
compiler
target
had
to
be
designed
so
that
it
could
run
very
fast,
otherwise,
web
assembly
applications
running
on
the
web
wouldn't
keep
up
with
users.
Expectations
for
smooth
interactions
in
gameplay,
there's
also
load
time
that
you
have
to
think
about
users
have
certain
expectations
about
how
quickly
something
will
load
for
desktop
applications.
That's
fast
because
it's
already
installed
on
your
computer
and
for
web
apps.
It
turns
out
it's
also
fast,
because
web
apps
usually
don't
have
as
much
code.
A
So
when
you
combine
these
two
things,
it
gets
a
little
tricky
desktop.
Applications
are
usually
pretty
large
code
bases,
so
when
they're
on
the
web,
there's
lots
to
download
and
compile
when
the
user
first
goes
to
the
URL.
So
we
needed
our
compiler
target
to
be
compact.
That
way,
I
could
go
over
the
web
quickly
and
these
languages
also
needed
to
be
able
to
use
memory
differently
from
the
way
that
JavaScript
used
this
memory.
They
needed
to
be
able
to
directly
manage
their
memory
and
to
say
which
bytes
go
together.
A
This
is
because
link
which
is
like
C
and
C++
have
a
low-level
feature
called
pointers.
You
can
have
a
variable
that
doesn't
have
a
value
in
it,
but
instead
has
the
memory
address
of
the
value
points
to
that
value.
So,
if
you're
going
to
support
pointers,
the
program
needs
to
be
able
to
write
and
read
from
particular
addresses,
but
you
can't
give
a
program
that
you
downloaded
from
the
internet.
Access
to
willy-nilly
just
run
around
in
your
memory,
using
whatever
addresses
at
once.
A
So,
in
order
to
create
a
secure
way
of
giving
access
to
memory
like
a
native
program
is
used
to,
we
had
to
create
something
that
could
give
access
to
a
very
specific
part
of
memory
and
nothing
else
to
do
this.
Web
'simply
uses
a
linear
memory
model
and
this
is
implemented
using
typed
arrays.
It's
basically
just
and
right,
like
a
JavaScript
array,
except
that
this
array
only
contains
bytes
of
memory.
So
when
you're
accessing
it
you're
just
using
the
array
indexes
which
you
can
treat
as
though
they
were
memory
addresses.
A
So,
with
all
of
these
things
in
place,
you
could
run
desktop
applications
and
games
in
your
browser
as
if
they
were
running
natively
on
your
computer,
and
that
was
pretty
much
that
the
skill
set
that
webassembly
had
when
it
was
released
as
an
MVP.
It
would
truly
was
an
MVP,
a
Minimum
Viable
Product.
This
allowed
certain
kinds
of
applications
to
work.
A
For
example,
the
arch
that
you
see
out
in
the
hall
was
programmed
entirely
with
MVP
features,
and
if
you
want
to
try
it
out
yourself,
you
can
actually
write
a
web
assembly
module
which
animates
this
space,
but
even
though
the
MVP
opened
up
some
of
these
use
cases,
there
was
still
a
whole
host
of
others
to
unlock
the
next
achievement.
To
unlock
is
heavier
weight.
Applications.
A
Can
you
imagine
if
something
like
Photoshop
were
running
in
your
browser?
If
you
could
load
it
on
any
device
like
you
can,
with
Gmail,
we've
already
started,
seeing
things
like
this,
for
example,
the
AutoCAD
team
has
made
their
CAD
software
available
to
the
browser,
and
adobe
has
made
Lightroom
available
using
web
assembly,
but
there
are
still
a
few
features
that
we
need
to
put
in
place
to
make
sure
that
all
of
these
applications,
even
the
heaviest
of
heavy
weight
applications,
can
run
well
in
the
browser.
A
The
same
instruction
run
across
all
of
these
execution
units,
but
they'll
all
be
acting
on
their
own
piece
of
data.
Another
hardware
capability
that
webassembly
needs
to
take
full
advantage
of
is
64-bit.
Addressing
memory
addresses
are
just
numbers.
So
if
your
memory
address
only
has
32
bits,
you
can
only
have
so
many
memory
addresses.
You
can
only
have
enough
addresses
for
4
gigabytes
of
linear
memory,
but
with
64
bits
addressing
you
have
16x
now,
of
course
you
don't
actually
have
16
exabytes
of
actual
memory
in
your
computer,
so
the
maximum
is
maximum
is
subject
to.
A
However
much
memory,
the
system
can
actually
give
you,
but
this
will
take
the
artificial
limitation
on
address
space
out
of
webassembly
for
these
applications
we
don't
just
need
them
to
run
fast.
We
also
need
these
load
times
to
be
faster
faster
than
they
already
were.
There
are
a
few
skills
that
we
need
specifically
to
improve
load
times.
A
One
big
step
is
to
do
streaming,
compilation
to
compile
a
web
assembly
file
while
it's
still
being
downloaded.
What
will
assembly
was
designed
specifically
to
enable
easy
streaming
compilation
and
in
Firefox
we
actually
compile
it
so
fast.
It's
actually
faster
than
it's
coming
over
the
network
that
your
file
is
pretty
much
compiled
as
soon
as
it's
downloaded
on
other
browsers
are
adding
this
capability
to
another
thing
that
helps
us
having
a
tiered
compiler
now
for
us
in
Firefox.
A
A
We
run
another
compiler,
the
optimizing
compiler
on
several
threads
in
the
background
now
this
one
takes
longer
to
compile,
but
it
generates
extremely
fast
code
and
once
it's
done
we'll
swap
out
that
original
baseline
version
with
that
fully
optimized
version
and
we're
actually
improving
this
even
further.
We're
working
on
a
new
compiler
called
crane
lift
as
designed
to
compile
code
quickly
because
it
can
do
it
in
parallel
at
the
function
by
function
level,
but
at
the
same
time,
the
code
it
generates
gets
even
better
performance
than
our
current
optimizing.
A
Compiler
crane
lift
is
already
in
the
development
of
version
of
Firefox
right
now,
but
it's
disabled
by
default,
once
we
enable
it
we'll
get
to
the
fully
optimized
code
even
faster,
and
that
code
will
be
faster
itself,
but
there's
an
even
better
trick
that
we
can
use
to
make
it
so
that
we
don't
have
to
compile
at
all
most
of
the
times
and
that's
caching
with
webassembly.
If
you
load
the
same
code
on
to
page
loads,
it
will
compile
to
the
same
machine
code.
A
It
doesn't
actually
need
to
change
based
on
what
data
is
flowing
through
it
like
JavaScript,
does.
When
you
have
JIT
compilation,
so
this
means
that
we
can
store
the
compiled
code
in
the
HTTP
cache
and
then,
when
the
page
is
loading,
it
goes
to
fetch
the
wasm
file,
we'll
just
pull
out
the
precompiled
machine
code
from
that
cache.
A
So
this
skips
compiling
completely
for
any
page
that
you've
already
visited
and
that's
still
in
the
cache,
and
there
are
other
ways
that
we
can
speed
this
up
even
further,
where
we
can
skip
even
more
work,
so
stay
tuned
to
see
what
else
happens
to
improve
load
times.
Where
are
we
with
supporting
these
heavyweight
applications?
A
Right
now
for
the
threading,
we
have
a
proposal,
it's
pretty
much
done,
but
a
key
piece
of
that
sheared
array
buffers
had
to
be
turned
off
in
browsers
earlier
this
year
and
they
will
be
turned
on
again,
but
turning
them
off
was
just
a
temporary
measure
to
reduce
the
impact
of
the
specter
security
issue.
It
was
discovered
in
CPUs
and
disclosed
earlier
this
year.
Progress
has
been
made
on
this,
though
so
stay
tuned.
A
A
It's
also
meant
for
regular
web
development
for
the
kind
of
web
development
that
you're
used
to
the
small
modules
kind
of
web
development,
where
small
web
assembly
modules
can
be
introduced
in
just
the
places
that
it
makes
sense
those
little
corners
of
your
app
where
it
has
to
do
a
lot
of
heavy
processing
and
these
places
that
can
run
faster
with
webassembly
and
again.
This
is
a
case
where
some
of
it's
already
happening.
You're
already
seen
some
of
these
small
modules
being
incorporated
into
places.
A
So
first
we
need
fast
calls
between
javascript
and
web
assembly
because,
if
you're,
integrating
a
small
module
into
an
existing
JavaScript
system,
there's
a
good
chance,
you'll
need
to
call
between
javascript
and
web
assembly
a
lot
so
you'll
need
those
calls
to
be
fast,
but
when
web
assembly
first
came
out,
these
calls
weren't
fast.
This
is
where
we
get
back
to
that
whole
MVP
thing:
the
minimal,
Minimum
Viable
Product.
A
The
engines
had
the
minimum
support
for
these
calls.
They
just
made
the
calls
work.
They
didn't
make
them
fast,
so
engines
need
to
optimize.
These
we've
recently
finished
our
work
on
this
in
Firefox.
Now
some
of
these
calls
are
actually
faster
than
non
inline
JavaScript
to
JavaScript
calls
and
other
engines
are
also
working
on
this.
A
That
brings
us
to
another
thing,
though,
when
you're
calling
between
javascript
and
web
assembly,
you
often
need
to
pass
data
between
them.
You
need
to
pass
values
into
web
assembly
or
you
need
to
return
a
value
from
a
web
assembly
function.
This
can
also
be
slow
and
it
can
be
difficult
too.
There
are
a
couple
of
reasons
why
it's
hard.
One
is
because,
at
the
moment,
what
assembly
only
understands
numbers
this
means
that
you
can't
pass
more
complex
things
like
objects
in
as
parameters.
A
A
A
But
that
means
that
the
web
assembly
module
isn't
really
part
of
the
JavaScript
module
graph
in
order
to
import
an
export,
like
you
do
with
JavaScript
modules,
you
need
to
have
that
integration
now,
just
being
able
to
import
an
export,
doesn't
get
us
all
the
way
they
are.
We
need
a
place
to
distribute
these
modules
and
to
download
them
from
and
tools
to
bundle
them
up.
What's
the
MPM
for
web
assembly.
Well,
what
about
NPM?
What's
the
web
pack
or
parcel
for
web
assembly?
A
A
There's
one
more
thing
that
we
need
to
really
do
well
in
existing
JavaScript
applications
and
that's
support
for
older
versions
of
browsers,
even
those
that
don't
know
what
web
assembly
is.
We
need
to
make
sure
that
you
don't
have
to
write
a
whole
second
implementation
of
your
module
in
JavaScript,
just
that
you
can
support
ie
11.
A
So
where
are
we
on
this
use
case?
Well,
calls
between
JavaScript
and
web
assembly
are
fast
and
Firefox
now
and
other
browsers
are
also
working
on
this
for
easy
and
fast
data
exchange.
There
are
a
few
proposals
that
will
help
with
this,
as
I
mentioned,
before.
One
reason
that
you
have
to
use
linear
memory
for
more
complex
kinds
of
data
like
objects
as
Spence's
webassembly
only
understands
numbers,
so
the
only
types
it
has
are
int
and
floats
with
the
reference
types
proposal.
This
will
change.
A
This
proposal
adds
a
new
type
that
web
assembly
functions
can
take
as
arguments
in
return,
and
this
type
is
a
reference
to
an
object
from
outside
web
assembly
like
a
JavaScript
object,
so
web
assembly
can't
operate
directly
on
this
object.
To
actually
do
things
like
call
a
method
on
it,
it
will
still
need
to
use
some
JavaScript
glue
to
call
that
method.
A
But
this
means
it
works
it's
slower
than
it
needs
to
be
that,
but
it
works,
but
to
speed
things
up.
There's
a
proposal
that
we've
been
calling
the
host
bindings
proposal
and
that
lets
web
assembly
modules
declare
exactly
what
needs
to
happen
to
marshal
the
data
on
import
and
export
so
that
that
glue
code
doesn't
need
to
be
written
in
JavaScript.
A
Now,
by
pulling
this
glue
code
from
JavaScript
and
putting
in
web
assembly
the
gooknae
optimized
a
way
when
you're
calling
built-in
web
api's
like
dom
functions,
there's
one
more
part
of
the
interaction
that
we
can
make
easier
and
that
has
to
do
with
keeping
track
of
how
long
data
needs
to
stay
in
memory.
If
you
have
some
data
and
linear
memory,
that
j/s
also
needs
access
to,
then
you
have
to
leave
it
in
there
until
the
jas
reads
the
data.
But
if
you
leave
it
in
there
forever,
you
have
what's
called
a
memory
leak.
A
How
do
you
know
when
you
can
delete
the
data?
How
do
you
know
when
JavaScript
is
done
with
it?
Currently,
you
have
to
manage
this
yourself.
Once
javascript
is
done
with
the
data.
The
jas
code
has
to
call
something
like
a
free
function
to
free
the
memory,
but
this
is
tedious
and
error-prone
to
make
this
process
easier.
We're
adding
we
crafts
to
JavaScript
and
with
this
you'll,
be
able
to
observe
objects
on
the
JavaScript
side
and
then
do
cleanup
on
the
web
assembly
side
when
that
object
is
garbage
collected.
A
So
these
proposals
are
all
in
flight.
In
the
meantime,
the
rust
ecosystem
has
created
tools
that
automate
this
all
for
you
and
that
polyfill
the
proposals
that
are
in
flight
one
tool
in
particular,
is
worth
mentioning
because
other
languages
can
use
it
too,
and
that's
called
wasm
bind
gen
when
it
sees
that
your
rust
code
should
do
something
like
receive
or
return
certain
kinds
of
J
s,
values
or
Dom
objects.
It
will
automatically
create
that
JavaScript
glue.
A
That
does
the
data
marshalling
for
you,
so
that
you
don't
need
to
think
about
it
and
because
it's
written
in
a
language
agnostic
way,
other
language
tool
chains
could
use
it
too
for
es
module
integration.
We
have
the
proposal
pretty
much
done
and
are
now
working
with
the
browser
vendors
to
implement
it
and
for
tool
chain
support.
There
are
tools
like
Waze
and
PAC
in
the
rust
ecosystem,
which
automatically
runs
everything
that
you
need
to
package
up.
Your
web
assembly,
module
for
EM
p.m.
and
the
bundlers
are
also
actively
working
on
support.
A
Finally,
for
backwards
compatibility,
there's
the
Oise
m2j
s,
tool
that
takes
a
wizened
file
and
spits
out
the
equivalent
j
s.
Now
that
j
s
isn't
gonna
be
fast,
but
at
least
that
means
it
will
work
in
older
versions
of
browsers
that
don't
understand
web
assembly,
so
we're
getting
close
to
unlocking
this
achievement
and
once
we
unlock
it,
we
open
the
path
to
another.
A
Two
one
is
rewriting
large
parts
of
things
like
JavaScript
frameworks
in
web
assembly
and
the
other
is
making
it
possible
for
statically
typed,
compile
to
JavaScript
language
to
compile
to
web
assembly
instead.
So
this
is
things
like
Scala,
Jas,
Elm
reason
for
both
of
these
use
cases.
Web
assembly
needs
some
high-level
language
features.
Now.
First,
let's
look
at
rewriting
parts
of
JavaScript
frameworks.
This
could
be
good
for
a
couple
of
reasons,
for
example.
Take
react.
A
One
thing
you
could
do
is
rewrite
the
Dom
diffing
algorithm
and
Rost,
which
has
very
ergonomic
multi-threading
support
so
that
you
could
easily
parallelizing
cores
in
the
user's
computer.
You
could
also
speed
things
up
by
allocating
memory
differently
in
the
virtual
Dom.
Instead
of
creating
a
bunch
of
objects
that
need
to
be
garbage
collected,
you
could
use
a
special
memory
allocation
scheme.
For
example,
you
could
use
a
bump
allocator,
which
has
extremely
cheap
memory
allocation
and
all
at
once,
the
allocation
everything
gets
removed
for
memory
at
once.
That
could
potentially
help
some
things.
A
A
Some
of
these
JavaScript
objects
will
need
to
point
to
things
that
are
linear
memory
and
sometimes
linear
memory
will
need
to
point
to
these
javascript
objects.
If
this
ends
up
creating
cycles,
it
can
be
trouble
for
garbage
collection.
It
means
that
the
garbage
collector
won't
be
able
to
tell
if
the
objects
are
used
anymore,
so
they'll
never
be
collected.
A
So
web
assembly
needs
integration
with
GC
to
make
sure
that
these
kinds
of
cross-language
data
dependencies
work,
and
this
will
also
help
languages
that
compile
to
JavaScript,
like
Scala,
js'
reason
or
elm,
because
these
languages
all
use
the
built-in
garbage
collector.
So
if
web
assembly
can
also
support
that
built-in
garbage
collector,
then
they
don't
need
to
change
how
their
GC
works.
A
A
You
can
polyfill
exception
handling
currently,
but
the
polyfill
makes
the
code
run
really
slowly,
so
the
default
when
compiling
to
web
assembly
is
currently
to
compile
without
exception
handling.
However,
since
JavaScript
has
exceptions,
even
if
you've
compiled
your
code,
not
to
use
them
jas
may
throw
one
into
the
works.
If
your
web
assembly
function
calls
a
j/s
function
that
throws,
then
the
web
assembly
module
won't
be
able
to
correctly
handle
that
exception,
so
languages
like
Russ
choose
to
abort.
In
this
case,
we
need
to
make
this
work
better.
A
Another
thing
that
people
working
with
Jas
and
compiled
to
jeaious
languages
are
used
to
having
as
good
debugging
support
dev
tools
in
all
major
browsers,
make
it
easy
to
step
through
JavaScript.
We
need
this
same
level
of
support
for
debugging
web
assembly
in
browsers
and
finally,
for
many
functional
languages.
You
need
to
have
support
for
something
called
tail
calls
I'm,
not
gonna,
get
too
deep
into
the
details
on
this,
but
basically
it
lets.
You
call
a
new
function
without
adding
a
new
stack
ring
to
the
stack
so
for
functional
languages.
We
need
to
support
this.
A
Where
are
we
on
this
for
garbage
collection?
There
are
two
proposals
currently
underway:
the
typed
objects
proposal
for
JavaScript
and
the
garbage
collection
proposal
for
web
assembly
type.
Two
objects
will
make
it
possible
to
describe
an
object's
fixed
structure
in
JavaScript,
and
this
will
be
discussed
in
an
upcoming
tc39
meeting
web
assembly.
Gc
will
make
it
possible
to
directly
access
that
structure.
Now.
A
This
proposal
is
under
very
active
development,
and
once
we
have
both
of
these
in
place,
both
Jas
and
webassembly
will
know
what
an
object
looks
like
and
can
share
that
object
and
efficiently
access
the
data
stored
on
it
for
garbage
collection.
Our
team
actually
already
has
a
working
prototype
of
this.
However,
it
will
still
take
some
time
for
these
to
go
through
standardization,
so
we're
probably
looking
at
sometime
next
year
exception
handling
is
still
in
the
research
and
development
phase.
A
There's
work
now
to
see
if
it
can
take
advantage
of
other
proposals
like
the
reference
types
proposal
that
mentioned
before
for
debugging
there's,
currently
some
support
in
browser
dev
tools,
for
example,
you
can
step
through
the
text
form
out
of
web
assembly
in
Firefox,
but
it's
still
not
ideal.
We
want
to
be
able
to
show
you
where
you
are
in
your
actual
source
code,
not
in
the
assembly
code.
The
thing
that
we
need
for
this
is
to
figure
out
how
source
maps
or
something
like
source
maps
are
going
to
work
for
web
assembly.
A
A
A
But
the
truth
is
the
things
that
you
see
in
the
browser:
the
HTML,
the
CSS,
the
JavaScript
they're,
only
part
of
what
makes
the
web.
They
are.
The
visible
part
they're
what
you
used
to
create
a
user
interface,
so
they're
the
most
obvious,
but
there's
another
really
important
part
of
the
web,
which
has
properties
that
aren't
as
visible.
That
is
the
link
and
it's
a
very
special
kind
of
link.
A
A
That's
what
enabled
us
to
form
these
global
communities
of
people
we
didn't
know,
but
if
all
we
have
is
the
link-
and
there
are
two
problems
that
we
haven't
addressed
the
first
one
is
so
you
go
to
visit
the
site
and
it
delivers
some
code
to
you.
How
does
it
know
what
kind
of
code
it
should
deliver
to
you,
because,
if
you're
running
on
a
Mac,
then
you
need
a
different
kind
of
machine
code
than
you
would
if
you
weren't
running
on
Windows.
That's
why
we
have
different
versions
of
programs
for
different
operating
systems.
A
Then,
should
a
website
have
a
different
version
of
the
code
for
every
possible
device
now,
instead,
the
site
has
one
version
of
the
code,
the
source
and
that's
what's
delivered
to
the
user.
Then
it
gets
translated
to
machine
code
on
the
user's
device.
The
name
for
this
concept
is
portability.
So
that's
great,
you
can
load
code
from
people
who
you
don't
know
who
don't
know
you
and
don't
know
what
kind
of
device
you're
running.
But
that
brings
us
to
a
second
problem.
A
If
you
don't
know
these
people,
whose
webpages
you're
loading,
how
do
you
know
what
kind
of
code
they're
giving
you
it
could
be
malicious
code?
It
could
be
trying
to
take
over
your
system.
Doesn't
this
vision
of
the
web
running
code
from
anybody
who's
linked?
You
follow
mean
that
you
have
to
blindly
trust
anyone
who's
on
the
web.
This
is
where
the
other
key
concept
from
web
assembly
comes
in.
A
That's
the
security
model,
I'm
gonna
call
it
the
sandbox.
Basically,
the
browser
takes
the
page
that
other
persons
code
and
instead
of
letting
it
run
around
willy-nilly
in
your
system,
it
puts
it
inside
a
sandbox.
It
puts
a
couple
of
toys
that
aren't
dangerous
into
that
sandbox
so
that
your
code
can
do
things,
but
it
leaves
the
dangerous
things
outside
of
the
sandbox.
A
Why
does
this
distinction
matter?
Why
does
it
make
a
difference?
If
we
think
about
the
web
is
something
that
the
browser
shows
us
using
HTML,
CSS
and
JavaScript,
or
if
we
think
about
the
web
in
terms
of
portability
in
the
sandbox,
because
it
changes
how
you
think
about
web
assembly,
you
can
think
about.
Web
assembly
is
just
another
tool
in
the
browser's
toolbox,
which
it
is
it's
another
tool
in
the
browser's
toolbox,
but
it's
not
just
that.
A
A
Now
you
may
be
thinking
that
already
happened
with
nodejs,
but
as
it
is
today,
no
doesn't
quite
get
us
there.
It
doesn't
give
us
full
portability
and
it
doesn't
give
us
the
same
security
of
the
same
confidence
to
run
untrusted
code.
Either
node
takes
JavaScript
from
the
client-side,
making
it
possible
to
run
it
on
servers
and
other
device.
So
that
gives
us
some
portability.
A
It
makes
it
possible
to
run
J
s
code
on
all
sorts
of
different
machines,
but
you
still
need
native
modules
in
a
lot
of
cases,
because
native
modules
often
perform
better
or
you
might
already
have
code
written
in
a
language
like
C,
which
you
want
to
reuse
in
your
app,
but
native
modules
aren't
running
the
engine.
They
have
to
be
compiled
for
a
specific
kind
of
machine
that
the
user
is
running
on
so
that
doesn't
give
us
full
portability.
We're
also
still
missing.
Security.
A
Node
could
have
taken
the
sandbox
from
the
browser,
but
no
made
the
design
decision
early
on
that
J
s
modules
would
have
full
access
of
dangerous
things,
so
jeaious
modules
can
do
things
like
write
and
read
files
on
your
machine.
These
capabilities,
things
like
direct
file
access
are
dangerous
toys,
those
dangerous
toys
that
aren't
available
in
the
browser
sandbox,
even
though
they're
dangerous,
though
the
kinds
of
use
cases
that
node
was
built
for
this
kind
of
accesses
makes
certain
a
sense.
A
The
thing
I
want
to
make
clear
here,
though,
is
that
Noah
made
a
choice
and
there's
really
that
node
had
a
choice
to
make,
because
with
the
way
that
the
JavaScript
engine
works,
the
only
functionality
that
jjs
has
access
to
is
what
you
give
to
it.
So
for
JS
modules,
no
could
have
made
a
different
choice
about
sandboxing,
but
for
native
modules.
Sandboxing
is
less
of
a
choice
now
for
notice.
A
moot
point.
They've
already
made
the
design
decision
that
jeaious
modules
are
going
to
be
able
to
do
this
dangerous
stuff.
A
So
no
point
in
thinking
about
how
you
could
restrict
native
modules
access
if
you're
running
a
node
application
on
your
computer,
then
you
basically
said
I
trust
this
code.
But
what
about
other
use
cases?
Would
it
be
nice
to
have
both
the
portability
and
the
security
of
the
web
to
be
able
to
run
untrusted
code
on
any
kind
of
device
and
not
really
think
about
it?
What
assembly
makes
this
possible
web
assembly
starts
with
the
advantages
of
j/s
Portability
and
the
ability
to
be
CN
boxed
and
what
it
adds
is
performance.
A
It
gives
developers
the
performance
they
need,
which
means
that
they
don't
need
to
resort
to
on
sand
box
native
code
to
get
that
performance,
so
web
assembly
takes
both
of
these
features
of
the
web
Portability
and
the
ability
to
run
seats
to
safely
run
untrusted
code
makes
it
possible
for
use
cases
outside
of
the
browser
to
have
them
to
use
cases
from
from
the
cloud
to
the
blockchain
to
the
Internet
of
Things.
I'll
talk
more
about
it.
A
So
what
can
we
do
with
note?
How
could
we
improve
node
with
web
assembly?
We
could
bring
full
portability
to
node,
like
I
said
before.
Node
gives
you
most
of
the
portability
of
JavaScript
on
the
web,
but
you
still
need
native
modules
in
a
lot
of
cases
which
are
written
in
languages
like
C
and
those
need
to
be
compiled
for
the
specific
kind
of
machine
that
the
user
is
running
on
now.
This
currently
happens
with
something
called
no
chip
and
that
compiles
when
the
user
installs
the
app.
A
Now,
if
these
native
modules
were
written
in
web
assembly
instead,
then
they
wouldn't
need
to
be
compiled
specifically
for
the
user's
machine.
Instead,
they
just
run
like
JavaScript
and
node
runs,
but
they
do
it
at
nearly
native
performance.
So
we
get
to
full
portability
for
code
running
inside
of
node,
you
could
take
the
exact
same
node
app
and
run
it
across
different
kinds
of
devices
without
having
to
compile
anything,
but
what
assembly
doesn't
have
direct
access
to
the
system's
resources?
We
actually
need
to
pass
in
the
functions
so
that
it
can
interact
with
the
system.
A
Just
as
we
do
with
js4
note,
this
will
probably
include
a
lot
of
things.
A
lot
of
the
functionality.
That's
in
the
C
standard
library
and
things
that
are
part
of
POSIX,
the
portable
operating
system
interface,
which
is
an
older
standard
that
helps
with
compatibility.
It
makes
it
so
that
you
can
create
apps
for
unix-like
operating
systems
without
having
to
target
specific
ones.
So
modules
would
definitely
need
a
bunch
of
paas
equations.
A
All
that
the
node
core
folks
would
need
to
do
is
to
figure
out
what
set
of
functions
they
want
to
expose
and
then
figure
out.
The
api's
of
those
functions
should
have,
but
wouldn't
it
be
nice
if
that
were
actually
something
standard,
not
something
that
was
constrained
just
to
note
but
could
be
used
across
other
platforms,
runtimes
and
use
cases
to
a
POSIX
for
web
assembly.
If
you
will
a
POSIX,
a
portable
web
assembly
system
interface,
and
if
that
were
done
in
the
right
way,
you
could
even
implement
the
same
API
I
for
the
web.
A
So
is
this
something
that
could
actually
happen.
A
few
things
are
working
in
this
ideas,
favour
there's
a
proposal
called
package,
name
Maps
that
will
provide
a
mechanism
for
mapping
a
module
name
to
a
path
to
load
that
module
from,
and
that
will
likely
be
supported
by
both
browsers
and
node,
which
can
use
it
to
provide
different
paths
and
thus
load
entirely
different
modules,
but
with
the
same
API
with
that
mechanism
in
place,
what's
left
to
do
is
actually
figure
out
what
functions
make
sense
and
what
their
interfaces
to
be.
A
There's
no
active
work
on
this
in
the
at
the
moment,
but
there
are
a
lot
of
discussions
that
are
heading
in
this
direction
right
now
and
it
looks
likely
to
happen
in
one
form
or
another,
which
is
good
because
unlocking
this
guess
is
half
way
to
unlocking
some
other
use
cases
outside
the
browser,
and
with
this
in
place,
we
can
accelerate
the
pace.
So
what
are
some
examples
of
other
use
cases?
A
One
of
them
is
things
like
CD
ends
and
serverless
and
edge
computing,
so
where
you
put
your
coat
on
somebody
else's
machine
and
they
make
sure
that
the
server's
maintained
that
your
code
is
running
close
to
your
users,
why
would
you
want
to
use
web
assembly
in
this
case?
There
was
a
great
talk
explaining
exactly
this
recently.
Fastly
is
a
company
that
provides
CD
ends
and
edge
computing
and
their
CTO
Tyler
McMullen
explained
it
this
way
and
I'm
paraphrasing
here.
A
If
you
look
at
how
a
process
work
code,
that's
running
inside
of
that
process
doesn't
have
boundaries,
functions
can
access
whatever
memory
they
want
and
they
can
call
whatever
other
functions
in
that
process
say
one
when
you're
running
a
bunch
of
different
peoples
services
in
the
same
process.
This
is
an
issue
now
see.
Unboxing
could
be
a
way
to
get
around
this,
but
then
you
run
into
a
scale
problem.
A
For
example,
you
could
use
a
JavaScript
vm
like
firefox,
a
spider
monkey
or
Chrome's
v8
and
you'd
get
a
sandbox
and
you
can
put
hundreds
of
instances
into
a
process,
but
with
the
numbers
of
requests
that
fastly
is
surfacing,
you
don't
just
need
hundreds
per
process.
You
need
tens
of
thousands
per
process
now.
Tyler
does
a
better
job
of
explaining
all
of
this
in
his
talk,
so
you
should
definitely
watch
that.
But
the
point
is
that
webassembly
gives
them
the
safety
speed
and
scale
that
they
need
for
this
use
case.
A
So
what
do
they
need
to
do
to
make
this
work?
They
needed
to
create
their
own
run
time,
which
means
taking
a
web
assembly
compiler,
something
that
can
compile
web
assembly
down
to
machine
code
and
combining
it
with
those
functions.
I
was
just
talking
about
for
the
web
assembly
compiler.
They
used
one
that
we're
working
on
Mozilla.
The
one
I
mentioned
before
crane,
lift
it's
very
fast
and
doesn't
use
much
memory
now
for
the
functions
that
interact
with
the
rest
of
the
system.
A
They
had
to
create
their
own
because
we
don't
yet
have
that
portable
interface.
So
that's
an
effort
that
will
have
to
be
duplicated
across
different
companies
in
different
use
cases.
What
if
we
didn't
just
have
that
portable
interface,
but
we
also
had
a
common
runtime
that
could
be
used
across
all
of
the
different
companies
in
all
of
the
different
use
cases
that
would
definitely
speed
up
development.
Then
other
companies
could
just
use
that
runtime
like
they
do
know
today,
instead
of
creating
their
own
from
scratch.
A
So
what's
the
status
of
this,
even
though
there's
no
standard
runtime,
yet
there
are
a
few
runtime
projects
there
in
flight.
These
include
watham,
which
is
built
on
top
of
LLVM
and
wasum
jet,
and
we're
planning
one
that's
built
on
top
of
crane
left.
It's
called
wasm
time
and
if
you
want
to
get
involved
with
that
feel
free
to
come
up
to
me
after
the
talk
we
can
talk
about
that
now.
A
One
thing
I
forgot
to
mention
about
why
web
assembly
is
useful
for
things
like
serverless
and
edge
computing
when
you're
running
on
somebody
else's
server.
They
need
to
figure
out
how
much
they're
gonna
charge
you
to
run.
That
code
need
to
figure
out
how
many
CPU
cycles
you're
gonna,
take
some
places.
Call
this
fuel.
They
figure
out
how
much
fuel
you're
using,
but
this
can
be
hard
to
do
with
different
programs
running
simultaneously
in
the
same
process
in
the
same
machine.
A
But
since
web
assembly
is
pretty
close
to
actual
assembly,
it
makes
it
easier
to
see
how
much
fuel
something
is
using.
Another
use
case
that
uses
the
concept
of
fuel
or
gas
is
the
blockchain.
Now,
unfortunately,
I
don't
have
time
to
explain
the
blockchain
both
because
this
talk
is
short
and
because
the
blockchain
is
soup
are
hard
to
explain.
But
there
are
some
versions
of
the
blockchain
that
can
really
benefit
from
webassembly.
A
A
Is
that
untrusted
code
problem
that
we
talked
about
before
up
until
now,
the
etherium
community
has
dealt
with
this
by
having
their
own
language
called
solidity
and
that
restricts
what
the
code
can
do,
but
that's
a
pretty
high-level
language
and
it
was
hard
to
calculate
how
much
gas
or
how
many
cycles
executing
that
code
is
gonna.
Take
so
web
assembly
is
a
good
option
for
them.
It
gives
some
security,
it
makes
it
easier
to
calculate
the
gas
cost
and
it
opens
up
smart
contracts
to
a
host
of
new
languages.
A
Now
these
blockchain
platforms
they're
almost
like
a
new
kind
of
operating
system,
but
what
assembly
can
also
abuse
in
more
traditional
operating
systems
now
to
be
clear,
I'm
not
talking
about
in
the
kernel,
although
some
brave
souls
are
trying
that
but
webassembly
running
in
in
ring
3
in
user
mode,
that
could
give
us
things
like
portable
CLI
tools
that
could
be
used
across
different
kinds
of
operating
systems,
and
this
is
pretty
close
to
another
use
case,
the
Internet
of
Things.
This
includes
things
like
wearable
technology
and
smart
home
appliances.
A
Now
these
things
are
usually
pretty
resource
constrained.
They
don't
have
much
computing
power
and
they
don't
have
much
memory
to
use,
and
this
is
exactly
the
kind
of
situation
where
a
compiler
like
crane
lifts
and
a
runtime
like
wow,
some
time
which
lying
because
they
would
be
efficient
and
low
memory,
and
there
are
also
so
many
of
these
devices
on
all
of
them
are
slightly
different.
Web
assemblies.
Portability
would
really
help
with
that.
So
this
is
one
place
where
web
assembly
has
a
future.
A
Now,
let's
zoom
back
out
and
look
at
the
skill
tree
I
said
at
the
beginning
of
this
talk
that
people
have
a
misconception
about
web
assembly.
This
idea
that
the
web
assembly
that
landed
in
the
MVP
was
the
final
version
of
web
assembly
now
I
think
you
can
see
why
this
is
a
misconception.
Yes,
the
MVP
opened
up
a
lot
of
opportunities.
A
It
made
it
possible
to
bring
a
lot
of
desktop
applications
to
the
web,
but
we
still
have
many
use
cases
to
unlock
from
heavyweight
desktop
applications
to
small
modules,
to
JavaScript
frameworks,
to
compile
to
j/s
languages.
It's
all
of
the
things
outside
the
browser
from
node
and
server
list
in
the
blockchain
and
portable
CLI
tools
and
the
Internet
of
Things.
So
the
web
assembly
that
we
have
today
is
not
the
end
of
the
story,
because
web
assembly
still
has
promised
to
keep
and
many
places
to
go
before
it.
A
Sleeps
now
before
I
finish
up,
I
just
want
to
give
a
little
bit
of
things.
I
really
enjoy
working
on
Mozilla,
because
I
get
to
work
on
cutting
edge
technologies
like
this,
but
I
also
enjoy
it,
because
I
get
to
work
on
exciting
problems
with
some
very
smart
and
interesting
people
and
I
have
a
chance
to
collaborate
with
two
of
them.
On
this
talk,
Luc
Wagner,
who
was
one
of
the
co-creators
of
azzam
Jasin,
was
a
major
driving
force
and
making
webassembly
happen
until
Schneider
right
who
leaves
our
web
assembly
developer
tools
team
at
Mozilla.