[MUSIC PLAYING] JAMES MILNER: I'm
a software engineer at a company called SitePen. I'm predominately working on
enterprise web applications. I'm also a Google Developer
Expert for web technologies, and you can find me
tweeting at my handle, which is JamesLMilner. So if you want to follow
me or ask me any questions, that's probably the best way
to kind of get hold of me. So yeah. I hope that this goes
smoothly and that you learn something new. So before we dive too
much into WebAssembly, I want to give a bit
of an understanding about why WebAssembly
kind of came about and why it came to exist. And one of the core
reasons for its existence is that people have
been trying to write native code in the browser
for a very long time, and they've mostly
been trying to do this through the avenue of plugins. So historically,
you might have heard of things like of ActiveX, which
was kind of a Microsoft thing, and the Netscape plugin
API, which kind of housed a bunch of other kind of
platforms such as Flash, Java applets, and later on
kind of Microsoft Silverlight. So then after about
2013, these things started to kind of die
off, so Steve Jobs kind of killed off Flash with his
announcement-- with the iPhone, and ActiveX kind of lost
some of its momentum because of the advances in
the web platform. So new things kind of started
to take their place, though. So we saw the Google Native
Client and associated APIs that came from Google, and that
was an attempt to allow people to write sandbox C and C++
code and run it in the browser. And Mozilla kind of had
a different take on it. They created this thing called--
or they came up with this concept of asm.js, and asm.js
is like a super strict subset of JavaScript, which
compiles from C and C++. But because it is
such a strict subset, it can do specific
optimizations to make sure that the compiler can produce
more performant code than just regular JavaScript. And so yeah, there's
this strong desire to write things that weren't
JavaScript in the browser, which-- I love JavaScript, but
I can understand why people would want to do that. And this is kind of where
WebAssembly kind of comes into it, because WebAssembly
is kind of inspired by some of these attempts. So some of you might have heard
of WebAssembly in passing. Maybe some of you
even looked into it. Maybe some of you even used it. But here's like a little
refresher for everybody. So yeah, as I was
saying, WebAssembly was inspired by those attempts. In particular, it was
inspired by asm.js. And the idea was that if we
could compile from like C and C++ and a bunch of other
languages to some very low level language, then we
could use that in this kind of sandboxed environment
in the browser. So WebAssembly is this
binary instruction format for a stack based
virtual machine. And that sounds
a little bit dry, but what that really allows
us to do in the web is that it allows us to compile that C
and C++ code into this kind of sandbox environment,
somewhere where we could traditionally only ever
write JavaScript natively in the browser. And the cool thing
about WebAssembly is it's kind of in keeping with
a lot of the ethos of the web, and it's trying to move away
from this kind of plug-in based attempt to do things. And if you-- like, I think
some of the interesting things about it are some of the
design goals that go into it, so the first of which is
that it's going to be fast. So the aim is to have
near native performance. It should-- and then also not
only near native performance, but also consistent performance. So one of the problems
with JavaScript is that sometimes the
performance characteristics are maybe unpredictable,
depending on which engine it's running on or depending if it's
like a hot path or a cold path. And so WebAssembly aims to
always be predictably fast. It also has this
compact binary format, so because it's binary format,
it's very well-compressed, which means that it's
smaller over the wire than maybe say something
like JavaScript. It's also efficient
to compile, because it can be compiled-- like it can
be compiled like streaming compilation, and it can also be
parallelized in its compilation as well. So it has some really decent
performance characteristics that kind of make it quick. The next thing is
it should be safe. So the code is validated
and it executes in a memory safe
sandbox environment. So this aims to prevent
data corruption and security breaches, which are obviously
quite important in the web, because we've been spent so
long trying to keep everything enclosed and to stop
web apps from, like, wrecking your computer. And the last thing is that
it should be portable. So it shouldn't make any kind
of architectural assumptions about the hardware that
it's running on-- it should support all modern hardware. It should interoperate
with the environment and be able to interoperate
with other Wasm programs or other
languages, for that matter. So it should kind of be
this like universal thing that can ideally talk to
kind of any environment or any other language. So yeah, those are
the three things. It's going to be fast,
safe, and portable, which on paper sounds pretty cool. But one of the problems
with a binary format is that it's quite hard
to maybe understand what's actually happening. So alongside the
binary format, we also have what's called
the WebAssembly text format, which looks a
little something like this. You don't need to worry
too much about what this program is doing. It's just to kind of give you a
feel for what this kind of text syntax looks like. So it's kind of this Lisp
like kind of representation. And the aim here is to
try and make it easier to be able to debug your
compiled Wasm programs. So it's got this text format,
which is really helpful. And as I was saying,
its aim is that it can be compiled from a
bunch of host languages, so you could take a program
that's written in one language and then be able to compile
that down to WebAssembly. So some example languages
that currently have support for WebAssembly include
Rust, C, and C++. Those are probably two of
the most common languages for working with WebAssembly. There's also Kotlin. There's also a Haskell compiler. There's something
called AssemblyScript, so if any of you have
ever used TypeScript, AssemblyScript is essentially
kind of a subset of TypeScript, which is quite a lot to
wrap your head around, because TypeScript is a
superset of JavaScript. Anyway, long story
short, it's a way of writing TypeScript and
compiling it to WebAssembly. And lastly, Go. Go has a native
compilation to WebAssembly. So yeah, we've got this kind
of whole host of languages, and I think this will kind
of only increase over time and their support will only
increase over time as well. So number one question I
always get asked is, will it replace JavaScript? And the simple answer
to that question is no. It's because WebAssembly's
initial goal is not to replace JavaScript,
because WebAssembly is very good at a
specific set of tasks. It's very good at
like, for example, kind of numeric operations, dealing
with large sets of data very quickly. So you can replace
[? hot pass ?] in your JavaScript code
or certain algorithms with WebAssembly
programs to speed up bottlenecks in your programs. And you can also
use it to open up a host of like
different applications that might not necessarily
have been possible before because of things
like performance limitations. So some examples of
things like that are games is a great example. 3D, like 3D mapping,
or even 2D mapping, because it's a lot of
data intensive work. Things like image manipulation
or video processing or audio software. So these are just some of the
examples of where WebAssembly might be a really great
use case if you're interested in using it. So how do we use it? So I'm just going to
show you a little cage snippet of using WebAssembly
from JavaScript in the browser. So trying to keep it as
simple and sweet as possible. So what we've got here, if you
skip the initial declaration and just look at where we go to
WebAssembly.compileStreaming. So we're using the
WebAssembly JavaScript API, which is baked
into the browser and also baked into node. And we can do
WebAssembly.compileStreaming, and then we pass it the fetch-- the response from our fetching
the WebAssembly program. All that's going to do is it's
going to compile the program, and then we're going
to get the module and then we're going to
instantiate the module. And WebAssembly allows you
to import things into it, so you can call
JavaScript functions from a WebAssembly program. So in this case,
we're just going to pass in a function
called imported func, and it's just going to log out
any argument that it receives. So that's the
second line there-- WebAssembly.instantiate
with the imported object. And then next we're going to
use the instance of the module to call one of our
exported functions from our WebAssembly program. What that exported
function actually does-- what simple Wasm
has-- is it's just a declaration of the number
42 and it just console logs out the number 42. It's probably like one of
the most simple programs, and that's why it's
called simple Wasm. So that's how you use-- that's how you would
use WebAssembly in the browser, also in Node. So it's quite easy
to get started, if you're using JavaScript
as your kind of host language for running WebAssembly program. So another response that
sometimes you hear people say is that, well, that's
all great, but we need to support a whole
bunch of different browsers. And what's really cool is that
WebAssembly support is actually really strong across
all the modern browsers. So realistically,
unless you need to support Internet
Explorer 11 or Opera Mini, then you should be good to go. So 86% of the global market
share can use WebAssembly. And if you need-- if you desperately
need to support IE 11, most of the compilation
tools-- well, not most of them, but some of the
compilation tools, will allow you to compile your
program not only to WebAssembly but also down to JavaScript. So it can compile to-- like, [INAUDIBLE]
script can compile down to asm.js, which is
what I was mentioning at the beginning-- this
strict subset of JavaScript-- and also WebAssembly. So it's not the end
of the world if you have to support IE 11, because
you can just have a fall back down to JavaScript,
and people who can support Wasm will
get the Wasm file and the people who can't
support WebAssembly will just get the JavaScript file. And the other thing that I
hear a lot is that, like, are people actually using it? So what I've done is I compiled
five examples of people-- companies who are
actually using WebAssembly in production today, the
first of which is Figma. So some of you might
have heard of Figma. It's kind of like a
collaborative interface design tool, so you can create--
if you're a designer, you can create
mockups and share them with the rest of your team,
share them with developers or whoever it might be. As they've leveraged WebAssembly
to improve the loading times of the documents
in their web platform. And what they
found was that when they switched to using
WebAssembly, the loading times for the documents-- you know, the designs-- were sped up by a factor
of three regardless of the size of the document,
which is really cool. It's just this like
linear improvement across the whole application. The next example
I've got is Unity. So Unity is a games engine
which has the possibility to compile your game
to a WebGL target, so for running predominantly
light in the browser. And they switched from using
asm.js to using WebAssembly, and what they found was
that reduced the code size-- the actual amount of bytes
and the amount of code that's actually shipped
to the end user. They found that it
improved the performance and it allowed them to grow
the memory usage at runtime. So it had a whole host of
benefits from switching. The next thing I want
to mention is AutoCAD. So it's like one of the
biggest CAD tools in the-- well, globally. And they had a
35-year-old code base and they converted
that to WebAssembly. So they were able
to take this, like, hardcore desktop
application and compile it to the web using
WebAssembly, which is super cool-- like, taking
this 35-year-old code base and then just putting
it on the web. I think that's awesome. The next thing I want
to give a shoutout to is Squoosh.app, which is
made by the Chrome Labs team. And this is basically
an example of how to create a really
performant web application. And it uses WebAssembly to
do the image compression, so it's all about-- it's
an image compression app, basically. You can upload an image
and it will compress it. And the algorithms that they
use are all-- all the libraries that they use are all
compiled to WebAssembly. And the last one I've
got for you is eBay. So eBay used WebAssembly to-- they have a barcode
scanner which was written in JavaScript, and they
found that it wasn't-- like, it wasn't detecting
all of the barcodes that they wanted to detect. So what they did was they
compiled a library from C down into WebAssembly,
and what they found was that they could
get 100% success rate by combining the
JavaScript implementation of the barcode reader and the
WebAssembly implementation. So that's five examples
of people actually using WebAssembly today. So the next thing is, what
about kind of like frameworks? Everyone wants to
know if you can use it with Angular or
React, or even, like, can I just update the
page using WebAssembly? And unfortunately,
the answer is not yet. But it's getting there. So one of the things that-- one of the limitations
of WebAssembly currently is that it only
really understands numbers. It doesn't have a concept
of more complex types like strings or structs
or arrays or objects. And this makes dealing with
complex types quite difficult. So for example, a DOM
node is a complex type. So there's a few
things that need to happen before
we can get to doing DOM manipulation in the browser
or integrating with frameworks. So the first thing is-- well, the first kind of
step is that we need to-- like, WebAssembly needs to
be able to take a DOM node and even if it can't
understand what it does, it needs to be able to
do something with it or accept that it
kind of exists, right? So for example, you could take
a DOM node past WebAssembly and then do something with
it with a JavaScript function that you've passed in. And to do this,
there's a specification called the references
type proposal, and the reference types
proposal essentially allows you to do that. It allows you to take an object
that exists on the JavaScript heap and then pass it through
and then call it again on the JavaScript side. And essentially
what this does is it allows you to avoid all this,
like, glue code and passing-- like, serializing
something in JavaScript, deserializing it in WebAssembly,
and then serializing it again back to JavaScript. So it kind of skips
out these steps. And this proposal is-- because it allows
you to get hold of objects that are on
the job script heap, it's the first step
towards garbage collection. And we need garbage
collection, because WebAssembly needs to know if a DOM node
has been garbage collected. Because if you're trying
to operate on something that has been garbage
collected, you're going to have a bad time. So yeah. The next step is this kind of
garbage collection proposal, and this will allow better
integration with the JavaScript garbage collector
and in turn, you can do stuff with frameworks
and just various things like DOM manipulation. So the next thing is being
able to call web browser APIs directly. So rather than having to
go through JavaScript, you can just go
and call a web API directly without having
to go through JavaScript. So there's this thing called
the web interface description language, and this basically
defines how browsers-- their types, their return
types and their parameter types that browser APIs take. So we need to have kind
of bindings to those APIs. But the problem there is
that the browser types are quite complex, right? So I was saying that
WebAssembly only takes numbers. So we need to do
something clever to be able to essentially
allow WebAssembly to call those APIs directly. And this comes down to this
binding to the web, whereby the Web IDL types,
and this is going to happen through
this thing called interface types,
which is basically like definitions of how
you map complex types back to WebAssembly. And by solving this problem,
by solving the problem of the browser being able to-- WebAssembly being able to
talk to the browser directly, you actually solve a whole
host of other problems, because you solve the
problem of WebAssembly being able to talk to
another language that has different types. So if you can create this
intermediate representation, then you can interact
with a whole bunch of different things. So not only the browser,
but potentially other languages and other
Wasm-like programs that were compiled from
different languages. So it allows for this kind of-- the interface types allows
for this universal kind of communication. So concluding. So will this change
the web forever? The short answer to me is, yes. I think it already
is and it already kind of has, to some extent. But to the full
extent in the future, it's kind of an unknown. It's still kind of a bit of
a wait and see kind of thing. At the moment, I think
WebAssembly really augments the current web platform. It allows us to do things that
we couldn't do necessarily before. So for example, like AutoCAD
compiling, their native desktop application which is
like a 35-year-old code base to the web, is
super, super cool. Yeah, so I mean,
for me right now, there's these
three solid reasons that WebAssembly is powerful
and will change the web. It's because you can have
consistent performing code, you can compile from libraries
in different ecosystems, so you can-- for example, the
barcode library, the C barcode library
that eBay used. You can just pick
and choose libraries from different ecosystems and
say yeah, I want to use those. And the last one is that it
kind of solves this issue that we've been having around
with native code and plugins. So it allows us to-- it's easier now
to envisage a web without the need for plugins. So yeah, I guess
the last thing I want to talk about is
with JavaScript that-- I think it's hard to
deny that JavaScript has pretty much changed the
world, or at least the tech world. So JavaScript started off as
this little browser language and now you've got
things like it's running in the
back end with Node or it's running on IoT platforms
with things like Johnny-Five or it's making cross
platform applications with things like React Native
or desktop applications with Electron. So it's just gone
on and spiraled to become so much
bigger than just, like, a web scripting language. It's kind of become
this ubiquitous language that just kind of runs
everywhere on every device. And I think that we're
still in the early stages of WebAssembly. We're still kind of
at this MVP stage, and it'll be really interesting
to see where WebAssembly goes in the future and if it goes
down this path of becoming this super ubiquitous platform. So to give you-- to put that into
perspective, there's a guy called Solomon Hykes, and
he was a co-founder of Docker. And he said "If Wasm and WASI"--
so WASI is the WebAssembly systems interface. It's a way to
interface with things like files and the network
and all that kind of stuff. So he said, "If Wasm and
WASI existed in 2008, we wouldn't have needed
to create Docker," because it's just kind of like
this universal format that languages can compile to and
so many different languages can interact with. You just write it once and it
just runs on the Wasm runtime. Yeah, so I think it's just
a really interesting point in time to kind of be looking at
and thinking about WebAssembly. That's me. Thank you very much. [APPLAUSE] [MUSIC PLAYING]
