[MUSIC PLAYING]
ALEX DANLO: Hi, everyone.
I'm here to talk to
you about WebAssembly.
As [INAUDIBLE] kindly
said, I did ride a car
across the desert, I
also flew on the Concorde
on frigging five points.
So I've had this obsession
with speed, which
is why I love WebAssembly.
It's fantastic.
And what you need to understand
is what it actually is.
Right?
It's a new capability
for the web.
It's a way that you can build
really high-performance code
and have it run inside
your web application.
It's also not a
replacement for JavaScript,
it works alongside JavaScript.
So what it enables you to do
is to take things like c++
and Rust and compile it into
what we call a WebAssembly
module, or WASM module.
And you can load that
into your web application
and call it from JavaScript.
Now, when we were developing
this, one of the things
was speed, right?
It runs extremely fast, it runs
at a small percentage slower
than true native code, but more
importantly, it's very secure.
So what WASM is it's
kind of a binary format
that was specifically designed
to be safer than JavaScript.
So the instructions
are very restricted.
It's proven, there's
a mathematical proof
in a published paper about
it, so it actually adds--
there's a whole security
layer by design.
And on top of that, it
runs inside Chrome sandbox,
so there are a couple
of layers of protection
there for you when you use it.
But probably a bigger
goal was portability.
So we wanted to win enable the
compile once, run everywhere
model, and so it
actually does run
across a whole lot of browsers.
So you might be wondering what
can you actually do with it?
Well, say you already have
a whole lot of native code,
you might have a native app
that runs on desktop or even
in an app store, and it
could be written in c++,
it could contain business logic.
Or you could have a game engine
that's also many, many man
years of invested time.
So you could have a
multi-million line code
by sitting out there in
your own native application.
Now, you might think
about bringing that over
into the web.
Now, during the keynote
yesterday, there
was this whole talk of
the new web capabilities,
if you have a native app, you
can now pull in the web browser
without the URL bar
at the top, which
was making the native app
kind of-- or the web more
native-like.
Well, WebAssembly
is the opposite end,
it's making your web
app more native-like,
it actually pulls in
these native things.
So picture this.
Picture a new video format.
So we all use various
video formats.
There's WebM,
there's H264, there's
a whole lot of video formats.
But if you're, say,
a developer that
decided to come up
with a whole new codec
or a still-image
codec, you might want
to deploy that across the web.
Now, you could do
two things, you
could wait for the
browser implementers
to actually implement
it, you could log a bug
against all the browser saying
implement my new cool image
format or my new video format.
Or you could just compile your
c++ code into a WebAssembly
module, load it in your web
app, and use that video format
everywhere without any changes.
DEEPTI GANDLURI: Hi.
I'm Deepti.
I'm a software engineer
on the WebAssembly team.
So you've heard Alex talk
about what WebAssembly is.
Why should you care?
Why is this relevant
to you today?
So more and more applications
are moving to the web.
You have audio decoders,
video decoders, game engines,
music applications,
and a whole lot
of other computation-intensive
applications.
And we want these to run
at near-native speeds
and not need to be
re-complied for each platform.
And that's exactly
what WASM gives you.
So
And that's exactly
what WASM gives you.
And we have Chrome,
Firefox, Safari, Edge,
all support the first
version of WebAssembly.
And Edge, in fact,
just shipped last week
and we're very
excited about that.
So what are some of the
big companies that are
using WebAssembly right now?
This is a gif of the
Unity game Tanks.
We have a screen shot
from the Epic Zen Garden
from the Unreal Engine.
And so we want to dig a
little deeper into why all
of these companies use WASM.
When you have a WASM module,
all of the module information
is encoded in a
dense binary format.
So what this means is, you
have smaller binary sizes,
you have faster loading,
faster decoding,
it's a smaller memory footprint.
And it's just fewer
bits over the wire,
so everything is faster.
So one of the things we want
to do with this presentation
is to showcase a different--
all of the variety of
applications and use cases
that WASM works really well for.
So WebSight is a demo, it's
a real time face detection
demo of--
it's a real-time performance
demo of face detection
algorithm that uses OpenCV.
For those of you that are
not familiar with OpenCV,
OpenCV is the open source
computer vision library,
and it's extensively used.
So let's switch to
the demo, please.
So as you can see
here, what we have is,
you have the
WebAssembly version,
which is OpenCV, that's
compiled to WASM running
on the left side, and
on the right side,
you have handwritten JavaScript.
The performance is measured
by the amount of time
it takes to detect Alex's
face in the video stream.
So as you can see, the
WASM version is currently
at about 16 to 18
frames per second,
and the JavaScript version is
at about 2, 3 frames per second.
What we want to show you
here is that the WASM version
is so much faster than
the JavaScript version.
Can we switch to
the slides, please?
So like I said, this is an
example of a large existing
CC++ codebase that was compiled
to WASM and ported to run
in the web.
And you can see that these are
significant performance gains.
The thing to bear
in mind here is
that the handwritten
JavaScript might not actually
be the fastest
JavaScript there is,
so the performance here
might be slightly inflated.
But you can still see that
the performance difference
is actually quite large.
If you want to check out
what is actually available,
that's WebSight, S-I-G-H-T,
so make sure you look
for the right thing.
ALEX DANLO: OK.
So when we were getting
this talk ready,
I was trying to think of
what we could kind of show
you to give you an idea of what
you could use WebAssembly for.
So it's, like, you know, we
all build websites, right?
And so these days,
your average website
is probably a megabyte
or so, and 80% of that
would likely be images.
So I don't know about you,
but my workflow is typically,
I'll take photos with
my camera or whatever,
and I'll put it into Photoshop
and I'll crop and tweak.
And then I'll adjust the quality
to try and get that image small
because we want to
save bytes on the wire,
we want to make
our pages smaller.
And part of that is
optimizing your images.
I don't know, Other people
use command line tools,
you could use your
favorite things.
So I thought, what
if we could actually
do that inside the browser?
So what I did was I took the
independent JPEG group codec,
so this is code that is in a
lot of production applications.
It's probably 20
years old by now,
so it's had many, many years
of debugging, it's rock solid,
it ships in production.
In fact, a derivative
of it is inside Blink
to decode JPEG images, but
we don't have a JPEG encoder
in Blink, right?
So what I thought is, why
don't I just take the IJG code,
compile it into a
module that I can then
load that module into my
page, and I can load images
and start playing with
the quality and size
to see what happens.
So step one, which I
encourage you all to do,
is to download
the Emscripten SDK
and install it on
your workstation.
So once you've
installed it, you will
have a bunch of
command line tools
that help you work
with web assemblies.
So this is what I do to
compile my old JPEG transcoder.
It's nice and simple.
So emcc is the
Emscripten C compiler.
Now, this flag,
-s WASM equals 1,
tells the compiler to generate
a WebAssembly module for me.
The next line, which
says, -s exported
functions is JPEG transcode,
exposes the C function
jpg_transcode to JavaScript,
courtesy of WebAssembly.
So you can actually put a
list of functions in here
and export all of them.
The next line, the
output, is jpgsquash.js.
So what that is Emscripten
generated glue code.
So that is JavaScript
code that manages
the WebAssembly module for you.
So it manages the interface,
it manages the loading,
it manages all the calls
in and out, et cetera.
And then, of course, the
last thing in my source
file, jpgtranscode.c.
So once you've done that on your
command line, it will build you
a JavaScript thing
called jpgsquash.js,
and a WebAssembly module.
And this is how you
use it from your HTML.
So the first thing you do
is put in the script tag,
which pulls in jpgsquash.js.
Now, what this does is, pulls
in the WebAssembly module,
hooks up all the glue
logic, and creates
a global object called Module.
And Module is how you
interface to your WebAssembly.
So the code that I
actually wrote myself,
or you write as a developer,
is something like this.
The first thing I
do is set a boolean
saying the WebAssembly
is not loaded.
Now the reason I do this is
because WebAssembly modules are
loaded asynchronously.
So what happens is that when the
first script line is executed,
it kicks off the
load and then it
kicks off the actual compile.
So in the background,
the browser
is compiling the WebAssembly
module to machine code,
while the rest of your
page is continuing to load.
So they're running in parallel.
Now, in a future
version of Chrome,
we're going to change this
and we're actually going
to have streaming compile.
So as the WASM module is
coming across the wire,
it will be compiling
at the same time, which
will give you faster startup.
So I set this property on
the Module object, which
is on runtime initialized.
I set that to a function,
and that function
will be loaded when my
WebAssembly is ready.
So it just sets the boolean
to say I can use this stuff.
And so this is the simple
function I wrote to bash JPEGs.
So it takes two
arguments, the source
is a typed array containing my
original compressed JPEG image.
The second argument
is the quality
I'd like to compress
that down to.
So if the WebAssembly is not
loaded, I just do nothing.
If it's loaded, I call this
function, JPEG transcode,
which if you recall
on the previous slide,
I had in my exports.
So this parses in
the source typed
array, the number
of bytes that it is,
and the quality I
want to set it to.
And under the covers, it
goes off to the C code that's
been compiled, it
decompresses the JPEG image,
it re-compresses it
with the new quality,
and returns it inside
that source typed array.
And the return value
from that function
is the number of bytes of
the newly compressed data.
Now, of course, I can't put
a typed array on my page
very easily, so what I need to
do is convert it to a BLOB URL.
So we parse in that typed
array into this function,
Make BLOB URL, which
creates a BLOB URL,
tags it with the
type image JPEG,
and then I can attach
it to an image node
or even put it as a
CSS background image.
So why don't we just go to
the demo and I'll show you
how this works?
OK.
So here is the beautiful UI,
the application that I've built.
And of course it's the
WebAssembly logo there.
So I could pick a file.
So say I've taken a
photo on my camera.
I can just click the Choose
File dialog, which of course is
being nice and slow on me.
There we go.
So I'll just pick this photo.
Here is a photo of my daughter.
And here I'm re-compressing
it at quality 5.
So you can see the
original image on the left,
you can see if you compress
it to Q5 on the right.
Now, If I just grab the slide
and bump it up to full quality,
I'll kind explain
why I'm doing this.
So this is 100% quality.
The image is
absolutely identical,
but it's 935 kilobytes.
Remember when I
mentioned a megabyte
for the typical webpage?
I don't want to
deliver a megabyte.
So I could play binary
chop or something.
Let's go somewhere
around the middle.
So at 45, it's gone
from 900k to 100k,
and still this image is
still not too bad, you can--
you almost can't really tell.
In fact, I can't really see
a lot of difference here,
I don't know about you.
So let's go smaller again.
So quality of 23.
Now, it's probably not so
clear on the projector,
you can actually see there are
few bands in the sky there.
But overall, the face is
still kind of recognizable,
the parrots are happy.
You know?
I might just ship this
because the subject is clear,
the sky is a bit bad, but
I've only got 68 kilobytes.
Now, the reason I'm
doing this in the browser
myself because I want to
actually hand-optimize
it using my eyes to decide
what it's going to do.
Because if you use an automatic
JPEG compression tool,
it will use things like
signal-to-noise ratio,
and decide to deliver
you an image that
is imperceptible
from the original.
And that's not what I want.
I want to deliver less
bytes over the wire.
So I'll just show you
one more image quickly.
So this is an image that I
took on Sunday with my Pixel 2.
So this is a butterfly
at the Californian
Academy of Sciences.
And again, I've compressed
this at 23 quality,
which is what I was using
for the previous photo.
It's only 54k.
But you'll notice in this
particular image, only
the center matters.
There's this butterfly, it's
in focus, and over the side
here, it's all blurry
because there's
a lot of depth of
field happening.
So, in fact, I could even
shrink this even more.
So we have 50k now.
And I experimented with
this before I went on stage.
So if you bump it
down to, say, 10,
that's still relatively
clear in the middle,
And, you'll notice
the background here,
like you can see
the blur on the left
and the blockiness on the right?
Well I don't care
about that blockiness.
You know?
So I can use my better
judgment to say, well,
that's blurred anyway,
I'll let it be blocky.
And in fact, this kind of
gives this artistic look.
And then I only shipped
37 kilobytes to my users.
OK.
So if we flip back to
the slides, please.
[APPLAUSE]
By the way, if you want
me to open source that,
just ping me on Twitter and
I'll happily publish it.
OK.
So that's what one person could
do as a bit of fun, right?
Something that I would do in
my day-to-day web workflow.
But now I want to
show you something
that's a bit more serious.
This is like a serious
engineering company
building a large-ish product.
So what I'm going
to talk about is
this thing called Construct3.
And what this is, it's an
in-browser game editor.
So it's like a full-blown IDE
but running inside the browser,
courtesy of WebAssembly.
Now, what they've
done here is they've
wrapped a whole lot of
public open source libraries
into an application that
combines the best of native
and the best of web.
And this is what I was talking
about earlier, like the keynote
may improve native
apps with web,
we're actually improving
web apps with native.
So what they bring
into their application,
they bring in a bunch of
open source libraries,
they use FFmpeg for video
encoding and decoding,
they use Box2D as
a physics engine,
they use zlib for
compression, they
use PNG Crush to squash
down their PNG images.
But they're not just
using native code,
they're also using a lot
of browser capabilities
so they're using HTTP2,
they're using Service Worker
they're using Web GL2, and
they fall back to Web GL1
if it's not available.
They use Web Audio for all their
sound, They even use WebRTC.
And so this is a
full-feature, rich app.
And one thing that's
really, really interesting
about the web experience is that
the size of the thing they load
is smaller than
their native app.
And you think about
that for a minute.
Because when they
ship the native app,
they have to compile all
those native libraries,
such as FFmpeg et
cetera, et cetera.
But then they need to use
the functionality that's
already built in the browser.
So things like WebRTC, compiling
that alone is like 2 and 1/2
meg.
So that has to be put
into the native app.
But when it's on the
web, they can actually
load a smaller payload, and it
actually loads a lot quicker
than the native app.
So can we switch back
to the demo, please?
I'll just show you
what this thing does.
It's-- OK.
So here is that IDE
running inside the browser.
If there wasn't a URL
bar, you'd probably
think this is like, you
know, Xcode or Visual Studio,
or something like that.
It's a full-featured
web-based game editor.
So it has things like--
there's the start page,
we have tree controls here,
we have proper tree controls
that work, we have
property pages,
we have this property
page here somewhere.
So, like, property
pages, we even
have, like, a preview of the
game that you're working on.
There in the window you
have inspectors on the left.
So at the moment, see
it says Press To Begin.
I could just go over
here to the tree control
and click on the text
that's displaying there.
And if I scroll down
in this inspector,
I can click multiple
things that way.
In text.
Then we can actually see here
is the text for the Press
To Begin.
I can just change that to Hello.
And it changes in
my preview window.
Or I can even go
into the editor,
like, in my kind of wesay weak
mode and pull up the dialog box
and change it to something--
can't even spell.
And then we actually change
these live in-app previews.
So this is actually doing a
lot of work in WebAssembly
and taking advantage of
the power of the browser.
So the people that
built Construct3 also
have all these great things,
like you can actually
start playing your game.
So you can-- where else--
OK.
Hit Play.
It's preparing the
images, packing the game.
And it pulls Up a new
window running this thing,
so I can actually start
playing this game.
So I can fly around and
start shooting things.
And as you can see,
it's nice and performant
because a lot of the
logic is actually
in native code running through
a WebAssembly module, which
is very, very nice.
Now, one of the things that
they've built with this IDE
is they've got all
the native code that
does all the magic
and the editing
and the tree
controls, et cetera,
but they've also used some
of the best parts of the web.
Now, what they've built is
they've built this thing called
Remote Preview.
And what Remote Preview does
is it creates this QR code.
I'm just going to
pull out my phone
and scan this QI code
quickly, which gives me
a URL which I can click on.
If I click on that
URL, you see it's
connected to this client,
client 62 on Android, right?
And what it's actually
doing, is it creates--
excellent.
I was actually going to
ask you all to do that.
[LAUGHTER] All right,
everybody, get your phones out.
Scan this QR code.
I'll leave it there for a while,
and get everyone-- many of you
want to do this as we can.
See if we can crash the server.
I think if we try
hard enough we can.
Keep going, come on.
So what this does
is this actually
takes advantage of WebRTC.
I'm going to keep scrolling up.
So WebRTC has this thing
called data channel,
and that lets you send
arbitrary binary data around.
And so, in fact--
how many have we got?
33?
You want to keep scrolling?
DEEPTI GANDLURI: Yeah.
[LAUGHTER]
ALEX DANLO: And they
slow down my load.
I'm only at 97.9% here, people.
Come on.
And I'm loading the images.
Anyway, it allows you to send
binary data around the place.
So that in their
IDE, they've actually
built WebRTC data channel to
talk to your mobile device,
and then send the WebAssembly
modules across and all
the images and the
entire game, and then you
can start playing the
game in your phone
straight from your
IDE and try it out.
So it's a very
powerful facility,
and hopefully some of you
will get it loaded in a minute
and can play.
Can we go back to
the slides, please?
DEEPTI GANDLURI: So we've
heard about projects
that are successfully
using WASM right now.
We've heard about a whole
bunch of these demos.
And I want to talk about
some really exciting things
that we're working
on for the future.
So first up we have threads.
So the threads proposal provides
low-level building blocks
for pthread-style shared memory
between threads or web workers
in this case, and concurrently
using Atomics and [INAUDIBLE]
So a lot of the existing native
libraries that are available
extensively use threads.
So adding threads
to WASM simplifies
porting multithreaded
applications to the web.
And as a developer,
this is functionality
that you can use in
your applications.
You can build
multithreaded applications
and have them work faster.
And what's really
exciting about this
is that this is coming soon.
We're actively working on it
and we should have something
for you to try by
the end of the year
and launch in the first
half of next year.
So because of the nature
of compilation targets,
debugging in WASM
is not always easy.
We have support for
basic debugging,
but we're actively
working on adding
source maps, memory inspection,
and all of that good stuff.
So it will make debugging
your application simpler
and help with figuring out
exactly what's going on
with your application.
What are some of the other
features that we're working on?
We're working on
adding CMD support.
What does this mean?
That means that
we're adding support
for vector instructions
that are used
in image, video processing,
cryptography, et cetera.
We are also working on
zero-cost exception handling.
So when you have CC++
applications that extensively
use exceptions, what
happens is that,
right now we're emulating
these using JavaScript,
but that's not really fast.
So we want to be able to
provide a way for these
to work in a way that
there's no overhead.
So a lot of this presentation
we've been talking about C,
C++ libraries, but what about
support for other languages?
To do that, we need
garbage collection.
We need to be able
to efficiently
allocate and manipulate
managed objects directly
from WASM code.
And there's a
proposal in progress
for adding GC support to WASM.
So, so far, you've seen a
variety of applications,
you've seen game engines,
you've seen image detection,
compression, modular
libraries, but how big can this
really get?
How about the size of the Earth?
Let's switch to
the demo, please.
ALEX DANLO: Thank you.
DEEPTI GANDLURI: So you've
seen a snippet of this in--
you've seen a snippet of this
in the keynote yesterday,
but we want to show you what a
complex application like Google
oh it looks like in practice
when it's using WASM.
Let's go to the
Empire State Building.
You can see that this is a
whole immersive application.
You've got some
awesome 3D content,
you've got knowledge
cards that tell you
what other interesting
sites are around.
So let's try Voyager.
Voyager is this really
interesting application
that lets you explore
different destinations
from around the world.
And I love traveling, so let's
see what interesting things
we have here.
So unusual city
streets, how about that?
So these are curated map
stories that are available.
So let's go.
So let's see if this actually
brings up Street View.
And what I want
to point out here
is that this is using
shaders, WebGL APIs, you know,
and seamlessly interfacing in
and out of the WASM runtime
to give you this incredible
immersive experience.
One of the criticisms about
Google Earth when it first
came out was that
it was Chrome-only.
Now, let's put this up in
Firefox and see what happens.
We'll give it a second to load.
But what we expect
to see here is
that this works just
as well in Firefox,
as well as it does in Chrome.
So to do an apples
to apples comparison,
let's look for the Empire
State Building again.
So you've got a very similar--
the same 3D content,
everything that's
available in Chrome that's
also available in Firefox.
So you can see that this
works in a truly portable way.
Switch back to slides, please.
[APPLAUSE]
I also want to give a
shout out to our colleagues
on the Earth team that have
worked in putting this to WASM
and made this such a seamless
experience, Tejio, Jordan,
and his team are here in person.
So if you have any
questions, please
feel free to find them
after the presentation.
Cool Cool.
So what we kind of wanted
to get across here today,
especially for all the
web developers out there,
is WebAssembly is ready now
for prime time production
applications.
We're super excited to see four
major browser engines already
ship this.
Edge shipped last week.
So we have Edge, Safari,
Firefox, and of course, Chrome,
shipping this now.
But also something
to keep in mind
is that it's not just
desktop browsers,
it's a mobile thing, too.
So Safari on iOS 11, as
well as Chrome on Android,
both support WebAssembly.
So you can build highly
performant applications
using native code for mobile
devices, which of course means
faster execution time, which
means less battery usage.
So this is why it's a
really exciting technology.
Not just that, but not
only the browser vendors,
I bet there are other
large companies working
with WebAssembly now.
So we've seen that Unity
and Epic are both using it,
so it is a true
game-changer for the web.
We also have Autodesk releasing
AutoCAD using WebAssembly.
So these large
players are using it
because they
realize this is kind
of a next-generation
high-performance web
application environment,
and you should
be taking advantage of it, too.
Because using
WebAssembly, you'll
build better applications
that will delight your users.
Thank you.
[MUSIC PLAYING]
