thank you for that great introduction I
am Lynn Clark and I make code cartoons
and I also work at Mozilla on things
like web assembly which as well I'll be
talking about today and I'm joined by
till Schneider right who leads our web
assembly tooling efforts and he'll be
filling us in on some of their work so
first off what is web assembly what
assembly is a way of running programming
languages other than JavaScript on the
web
up until now to run code on a web page
the only language you could use was
JavaScript but now that there's web
assembly you can use other languages
like C or C++ or rust I've noticed that
some people have a misconception about
web assembly though people think that
the MVP that landed in browsers and 2017
is the final version of web assembly and
I can understand where that
misconception comes from because the web
assembly CG is really committed to
backwards compatibility so the web
assembly that you write today will
continue to work far into the future but
that doesn't mean that its feature
complete and that's far from the case in
fact features are coming to web assembly
which will fundamentally alter what you
can do with web assembly I think of
these future features kind of like the
skill tree in a video game we've fully
filled in the top few of these skills
but there's still this whole skill tree
underneath to unlock so that we can
unlock all of these different
applications so let's look at what's
been filled in already and then we can
see what's yet to come
webassembly story starts with unscripted
which made it possible to bring large C
and C++ code bases to the web for things
like desktop applications and games and
it did this by transpiling that code to
JavaScript and at first that JavaScript
would run pretty slow but then the
Firefox engineer saw how you could add
optimizations to the j/s engine to make
it run fast and that gave us has enjoy
us once the other browser vendors saw
how fast as andreas was they started
adding the same optimizations to their
at engines as well but that wasn't the
end of the story it was just the
beginning
engines could still make this go faster
but they couldn't do it in JavaScript
itself instead they needed a new
language
one that was designed specifically to be
compiled - and that was webassembly
so what word the skills needed for this
MVP this Minimum Viable Product running
c and c++ on the web web assemblies
designers knew that eventually they
would want to support languages other
than just C and C++ so they needed a
language agnostic compile target
something like the assembly language
that things like desktop applications
are compiled to like x86 but this
assembly language wouldn't be for an
actual physical machine it would be for
a conceptual machine that compiler
target had to run very fast to meet
users expectations for smooth
interactions and gameplay and it also
needed to load fast because the web's
users are used to pretty fast load times
but these kinds of applications are very
large code bases which means that
there's a lot to download when you first
visit the URL so we needed our compiler
target to be compact so it could go over
the internet quickly these languages
also needed to manage memory differently
from JavaScript they need to be able to
directly manage their memory and this is
because languages like C and C++ have a
low-level language feature called
pointers the in pointers need to be able
to take a memory address and read and
write directly from that memory address
but you can't have a program that you
downloaded from the web just accessing
your memory willy-nilly in order to
provide a way to access memory like a
native program is used to but to keep
the browser secure we had to create
something that could give access to a
very specific part of memory and nothing
else to do this web assembly uses a
linear memory model and that's
implemented using typed arrays which are
basically just JavaScript arrays except
the the items that are in this array are
bytes bytes of memory so when you're
accessing it you're just using array
indexes which you can treat as though
they were memory addresses and this
means that you can pretend that this
array is C++ memory so with all of those
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 the
skill set the web assembly had one was
released as an MVP it truly was an MVP a
Minimum Viable Product
this allowed certain kinds of
applications to work but there was still
a whole
host of other applications that needed
to be unlocked so the next achievement
to unlock is heavier-weight desktop
applications can you imagine if
something like Photoshop was running in
your browser if you could load it on any
of your devices and start working with
your files like you can with Gmail we've
already started seeing things like this
for example the AutoCAD team has made
their CAD software available through the
browser and adobe has made Lightroom
available through the browser using web
assembly but there are still a few
features that we need to make sure all
of these applications even the heaviest
of heavy weight applications work well
in the browser first as support for
multi-threading modern-day computers
have multiple cores that can process
things in parallel but to make use of
these cores you need support for
threading there's another bit of modern
hardware that processes things in
parallel and that sim date single
instruction multiple data what cindy is
possible to take a chunk of memory and
split it up across different execution
units which are basically like cores and
then you have the same bit of code the
same instruction run across all of those
execution units but on different parts
of the data
another hardware capability is 64-bit
addressing memory addresses are just
numbers so if your memory addresses are
only 32 bits long you only have so many
memory of Justis enough for gigabytes
but most modern hardware supports 64-bit
addressing which offers 16 exabytes of
memory addresses that's a big difference
adding 64-bit support will take the
artificial limitation on memory address
space out of webassembly
but these applications don't just need
to run fast load times need to be fast
too one mix-up here is to do something
called streaming compilation where you
compile the file as it's being
downloaded and web assembly was designed
to enable this tiered compiler also
helps so in Firefox we have two
compilers the first one the baseline
compiler starts when the download starts
for the first time then another compiler
the optimizing compiler runs on several
threads in the background and that one
takes longer to compile but the code
that it generates is extremely fast
we're also working on a new optimizing
compiler called crane lift and crane
lift is designed to actually speed up
that initial compile time so it can
compile a code in parallel at a function
by function level but the code it
generates is still fast and we're
currently working to see if we can make
it generate code that's even faster and
when it's executing then our current
optimizing compiler but there's an even
better trick we can use to skip
compiling most of the time unlike with
JavaScript if you load the same web
assembly file twice it compiles to the
same machine code so we can store that
compiled code in the HTTP cache and then
when the page is loading and it goes to
check the cache instead of pulling out
that source code it pulls out the
compiled code so this skips compiling
completely and there are ways to skip
even more work so stay tuned to see what
else happens to improve load times where
are we with supporting these heavyweight
applications right now for the threading
we have a proposal that's pretty much
done but a key piece of that shared RAID
buffers had to be turned off in browsers
earlier this season last year they will
be turned again turned on again soon
though cindy is under active development
at the moment for 164 we have a good
picture of how this is going to work and
that's pretty similar to how x86 or arm
got support for 64-bit addressing and
Firefox added streaming compilation last
year in Firefox we actually compile the
code so fast that's basically done
compiling by the time you've downloaded
the file and other browsers are adding
streaming too and we also added our
baseline compiler last year and other
browsers have been adding the same kind
of architecture in Firefox HTTP caching
is close and it is in closing Chrome as
well and other improvements are in
discussion even though this is all still
in progress heavyweight applications are
still coming out today because
webassembly already gives these
applications the performance that they
need but once these features are all in
place there's going to be another
achievement unlocked and more of these
heavyweight applications are going to be
able to come to the browser but web
assembly isn't just for desktop
applications it's also meant for regular
small modules developed web development
the kind of web development that you're
used to
if you have a module that does a lot of
heavy computation or processing that's a
good use case for web assembly and again
we're already seeing some of this
so the parser in the source Maps library
that's used in web pack and Firefox dev
tools that was rewritten in Russ
compiled to web assembling there's now
11 times faster and the Gutenberg parser
and WordPress is now an average of 86
times faster with its rewrite and rust
compiled to web assembly but for this to
go mainstream we need to have a few more
things in place first calls between
javascript and web assembly need to be
fast when web assembly first came out
these calls weren't fast because engines
needed to optimize them we finished our
working on this in Firefox last summer
and now some of these calls are actually
faster than non inline JavaScript to
JavaScript calls that brings us to
another thing though you often need to
pass data between your JavaScript and
web assembly functions you need to pass
arguments into your web simulator or
return values from it at the moment web
assembly only web assembly only
understands numbers so this means that
you can't pass more complex things than
like objects you need to convert your
object into numbers put it in a linear
memory and then pull it back out on the
web assembly side and figure out what it
is that's kind of complicated and it
takes some time to convert the data into
linear memory so we need this to be
easier and faster we also need to
integrate with es modules right now you
can't use import and export with Wazza
modules but that means that the web
assembly module isn't really part of the
J's module graph just being able to
import and export doesn't get us all the
way there though we also needed ways to
distribute and bundle web assembly
modules what's the MPM for web assembly
well what about NPM what's the web pack
or parcel for web assembly well what
about web pack and parcel these modules
shouldn't look any different to the
people that are using them so why should
we create a whole other ecosystem and
there's one more thing support for older
versions of browsers even those that
don't know what web assembly is like ie
11 so where are we on all of these
things
well calls between JavaScript and web
we're fast and Firefox now and other
browsers are also prioritizing this for
easy and fast data exchange there are a
few proposals that will help with this
such as any rough post bindings and weak
refs and I unfortunately don't have time
to go into the detail on that but in the
meantime the rust ecosystem has created
tools that automate the handling of this
stuff for you for es module integration
the proposal is pretty far along for
tool chain support tools in the rust
ecosystem can package your code for NPM
and the bundlers are also actively
working on support and finally for
backwards compatibility there's the wasm
2j s tool that takes a wizened file and
spits out the equivalent java script now
that javascript isn't going to be fast
but at least it will work in older
versions of browsers that don't know
what web assembly is once we unlock this
achievement we open the path to another
to rewriting large parts of JavaScript
frameworks and web assembly and making
it possible for statically typed compile
to JavaScript languages to compile to
web assembly instead languages like
Scala jeaious or reason or elm for both
of these use cases weba simply needs to
support high-level language features so
first let's look at rewriting parts of
j/s frameworks for a framework like
react you could paralyze the virtual Dom
dipping algorithm with a language that
has really economic support for
parallelization like rust and you can
also speed things up by reducing memory
usage and allocating memory differently
but you still need to interact with
JavaScript objects things like
components from that code
you can't just rewrite everything in
linear memory because that would be
difficult and inefficient so you need to
be able to integrate with the browsers
built-in garbage collector and that will
also help languages that compile to
JavaScript like Scala GS reason and elm
because these languages they already use
Java scripts garbage collector when they
compile to j s and that's the same GC
that web assembly will be Rutt using
when it's running in the browser so they
won't need to change their GC we also
need better support for handling
exceptions and we need good debugging
support browsers today make it easy to
bug your your JavaScript using dev tools
we need that same kind of support for
web assembly and finally for many
functional link
justyou need a feature called tail calls
so where are we on all of this for
garbage collection our team already has
a prototype of this working but it will
still take some time for these proposals
to go through standardization so we're
probably looking at sometime next year
exception handling is still in the
research and development phase for
debugging there's currently some support
and browser dev tools but it's still not
ideal so there's a subgroup of the web
assembly CG that is working on
specifying that and the tail calls
proposal is also underway once those are
all in place we'll have unlocked J's
frameworks and many compiled to j/s
languages so those are all achievements
that we can can unlock inside of the
browser but what about outside the
browser now you may be confused when I
talk about outside the browser because
this is the browser what you use to view
the web and isn't that right in the name
web assembly but the truth is
technologies like HTML and CSS and
JavaScript are only part of what makes
the web they're the visible part they're
what she used to make user interfaces so
they are the most obvious part but
there's another really important part of
the web which has properties which
aren't as visible and this is the link
the links innovation is that I can link
to your page without having to put it in
a central registry or ask you or even
know who you are it's this ease of
linking that enabled us to create these
global communities with people that we
don't know but there are two problems we
haven't addressed if we just have this
link the first one is 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 to
have a different kind of machine code
than if you're running on Windows does
the website need to have a different
version of the code for every possible
device no instead the site has one
version of code the source code and
that's what's delivered to the user and
that is translated to machine code on
the user's device the name for this
concept is portability with it websites
don't need to know what kind of device
you're running but that brings us to a
second problem if you don't know these
people whose webpages you're visiting
how do you know what kind of code
they're going to give to you it could be
trying to take over your system doesn't
this vision of the web running code from
anybody who's a link you follow mean
that you have to blindly trust anyone
who's on the web this is where the other
key concept from the web comes in and
that's the security model basically the
browser takes the code and puts it in a
sandbox and it puts a couple of toys in
that sandbox that make it possible for
the code to do some interesting things
but it leaves the dangerous toys outside
of the sandbox
so the utility of the link is based on
these two things the portability being
able to deliver the same code to all
these different devices and have it run
and the sandbox the security model that
lets you run the code without putting
your machine at risk so what difference
does it make if you think of the web
this way it changes how you think of web
assembly you can think about web
assembly is just another tool in the
browser's toolbox which it is but it's
not just that what assembly also gives
us a way to take these other two
capabilities of the web the portability
and the security model and bring them to
use cases that need them to outside of
the web we can expand the web past the
boundaries of the browser now you may be
thinking that already happened with
nodejs
but as it is today note doesn't quite
get us there it doesn't give us full
portability and it doesn't give us the
same security the same ability to run
untrusted code either
so James modules is using with node it's
possible to run JavaScript on servers
and other devices that don't have a
browser so that does give us some
portability but you still need native
modules in a lot of cases either because
you need the code to run really fast or
you already have code written in a
language like C that you want to then
use in your app but native modules
aren't portable they have to be compiled
ahead of time specifically for the kind
of device the users using we're also
still missing security node could have
taken the sandbox from the browser but
node made the define decision early on
that J's modules would have full access
to certain system api's so J's modules
can do things like write and read file
on your machine these capabilities
things like direct file access to your
system are the dangerous toys that
aren't available in the browser sandbox
even though they're dangerous though for
the kinds of use cases that node was
built for these these api's do make a
certain kind of sense this kind of
access makes a certain kind of sense the
thing I want to make clear here is that
node made a choice really is that node
had a choice to make
4j s modules it could have gone with a
sandbox style approach but for native
modules node had less of a choice
because it's really hard to sandbox
native code so notice made this choice
basically if you're running a node
application today on your computer
you've basically said I trust this code
although the node developers are
actually looking at a way that they can
change this in the future but despite
this webassembly can still help node it
could eliminate most of the need for
native modules ones that are compiled
ahead of time for the user's device
these could be written in webassembly
instead and just compiled once and these
modules could then run across all
devices just like JavaScript modules do
the only problem here is that web
assembly doesn't have direct access to
the system's resources we would need to
pass in functions to the web assembly
module so they can work with the
operating system now for note this will
probably include a lot of the
functionality of things like the c
standard library and things that are
part of POSIX the portable operating
system interface which is an older
standard and helps with compatibility
across different kinds of operating
systems unix-like operating systems to
make that happen the node core folks
would need to figure out what API they
want to use for these functions but
wouldn't it be nice if that were
actually something standard not
something that was constrained just to
node but could be used across other
runtimes and use cases to a POSIX for
web assembly if you will a POSIX a
portable web assembly system interface
and if this were done in the right way
you could even implement the same API
but in a different way for the web now
these functions wouldn't be part of the
core web assembly spec and there would
be web assembly hosts that didn't
include them but for platforms that
could make use of them
there would be a unified API for calling
these functions no matter which platform
your code was running on and this would
make universal modules ones that run
across both the web and node so much
easier so is this something that could
actually happen
well we and others are working on it and
I think we have a pretty good chance and
we are also seeing a lot of demand for
this from a wide range of that with
different domains one of these domains
is the domain of CD ends of service and
off top computing the fastly CDN for
example serves a significant fraction of
the entire Internet traffic and they are
moving from serving just static files as
Citians have historically done to
running their customers code on every
incoming request and they are doing this
without adding ten times as many
machines to their network which is
really what they would have to do if
they were to use more traditional server
architectures where you'd use something
like containers or other heavy wage
mechanisms to one untrusted code instead
webassembly gives them the sandboxing
they need at the speed and at the scale
that they need people are also working
on building blockchain platforms with
web assembly this interest in the IOT
space and in a world of reading portable
CLI tools with web simply we've also
seen interest from companies building
game engines where web simply can be
used to run game logic in sandboxes and
with projects like wasn't written a
beulah some folks try to make it one
inside of weddings
and criminals I don't have time to
explain all these difficult use cases
and what exactly makes assembly good for
them but there are some important
considerations but for example they all
have in common that sandboxing and
portability are important for them and
there are some other important
commonalities which I want to talk a bit
more about for example how do things
like network access work of file access
the way these things work should ideally
be roughly identical across all of these
use cases or exactly identical if you
use webassembly together with javascript
in the browser or a node then javascript
is used to let webassembly talk to the
outside world you use fetch to load a
file from a server in the browser all of
this is standardized so you can rely on
it and you use nodes FS thought we'd
file to read a file and you can also
rely on this but for a different reason
there's really only one runtime you
would use note because node is the de
facto standard
you know the api's you can use and can
rely on ideally we all have a similar
situation with web assembly where you
know what api's you can work with but
not with one runtime being completely
dominant instead we are working towards
the standardized runtime environment
which means there'll be a set of
functions that you can rely on for
things like file access or network
access that means you can compile code
once and run it in all of these
different environments and in any one
time that provides these functions or on
the browser where these functions can be
implemented in using javascript using
existing Dom API and then you can have
at one time so that really tailored
towards their exact use case instead of
having to rely on
size fits all so for this standard lab
we we could have said let's just use
POSIX and be done with it
unfortunately that eliminates one of
webassembly big advantages security
model it's security model and in
particular the sandbox england talked
about lin also talked about how node had
a choice to make at least four
javascript modules its choice between
keeping the sandbox that j s runs in in
the browser or giving it an easy way to
talk to the outside world and we now
have the same choice to make do we go
with this easiest route but give up on
sandboxing or do we do something
different something that allows better
control and leads to better security and
auditability and that last point is
really important if you run an
application or before you run an
application ideally you should be able
to tell what it can do to your machine
sort of in the worst case can it access
your entire file file system and then
just send off things to the internet say
your Bitcoin wallet maybe not run that
machine maybe that that application but
if it can only access files in a single
directory and right back to that effect
we seems fine now with POSIX that isn't
quite a be hard and it really only works
with support from the operating system
and how this works is different between
different operating systems so there
goes a lot of your portability solid
portable sandboxing is hard equi note
was created nobody had really figured
out how to apply it to the real world
but with things such as Google's fuschia
operating system this has changed better
designs exist and for well some time we
are working on a standard lab between
that will make it easy to build secure
auditable and portable modules and
application
that'll work for all of these different
use cases so with the standardized API
you could get the same flexibility that
you have with note but still have
security audit ability and the ability
to run your code in very different
runtimes and we are making sure that you
can use the tools you are used to as
well the compilers for languages such as
C C++ and others and the debugger
such as ll DB and gdb and IDE such as
Xcode and Visual Studio code so as you
can see there's a lot of active
development in this space we are all
working hard to make it easy for you to
target these different use cases without
making you jump through hoops to develop
and debug your code and with this we
bring these capabilities of the web that
Lynn mentioned the Portability and
security and the audit ability that I
mentioned to all of these use cases 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 and I think you can see now why
this is a misconception yes the MVP
opened up a lot of opportunities and
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 all of those things outside of the
browser node and serverless in the
blockchain and portable CLI tools in the
internet of things so the web assembly
that we have today is not the end of the
story because what assembly still has
promised to keep and many places to go
before it sleeps I want to thank my
collaborators on developing this talk
luke Wagner until Schneider right and
thank you all for listening
you
[Music]