WebAssembly will enable us to do something
we have been working on solving for the past decade.
Yeah, the Web has always been a convenient
and secure way for users to access content.
If you want to run any code in a web browser,
it's gotta be JavaScript.
Which is a nice language, but it's far below
native levels of performance.
JavaScript has gotten far, far faster than it used to be
five or ten years ago, and even in the last few years,
it's gotten even faster with things like asm.js,
which really allowed us to already run
large applications, like game engines,
but still there's just a few areas where JavaScript
and asm.js can't give us the full speed,
that you can get in the native application
and you need to really design the executable format
kind of from scratch in a proper way,
and that's what WebAssembly is.
One of the big differences between WebAssembly
and JavaScript is that JavaScript was first and foremost
a language that was built for humans to write and read,
and eventually browsers got very fast
at executing that code.
WebAssembly, on the other hand, is designed
first and foremost as a compiler target,
so it's built for what compilers want to emit
and what is efficient for browsers to execute.
But in general, you will just take a language like C++
or Rust and compile the code down to WebAssembly.
For asm.js and WebAssembly to work properly,
there are two parts.
One is a tool chain that compiles the C++ or Rust,
or other language into the compiled code,
and then we need to be able to run the compiled code
in the browsers.
When you use a compiler like LLVM,
which is what we use sort of to start
the compilation process,
the output that it gives you is basic blocks and branches,
but you're compiling to JavaScript,
which is a structured language.
We have "ifs" and "whiles" and "do while" loops,
so you have these high level control flow structures,
that are very different than what a compiler gives you.
Early approaches to this basically just sort of emulated
the control flow by generating something
as similar as possible to those basic blocks and branches,
just using a switch and a loop, and that works,
but it's quite slow, and I came up with a way
that basically recreates a similar control flow structure,
that you had in the original code, that you compiled.
So, it looks at the basic blocks
and it finds where there's really a "loop",
where there's an "if", and it then creates
those "ifs" and those "loops".
Often this would make you three, four times faster
than the older approaches.
What WebAssembly does is it gives you a way to emit code,
that is smaller over the wire, when you're sending it
to the web browser, and allows the web browser
to really efficiently pull it into memory
and prepare it for execution, and then when it runs it
to very quickly run at high performance.
Obviously JavaScript is essential.
It's critical to the Web.
It's not going anywhere, but we're empowering
a whole new slew of audience.
I started to work on this area at around 2010
juts kind of as a hobby, I was curious to see
what we could run on the Web in terms of code,
that we compiled from a language like C++.
I basically started an experiment in my own spare time
to see how this can work,
and that eventually turned into the Emscripten project.
I remember the first time I actually met Alon
was on a plane and he learned
that I was on the JavaScript engine,
and he said, "Hey, I have this project, Emscripten.
It's built on LLVM, it compiles C++ to JavaScript."
and my very first impression was, "Wow!
"That sounds slow."
Like, that'll run way worse than if I just wrote the code
by hand, because of course you have to write it by hand.
It was quite slow.
It generated code that ran maybe five,
ten times slower than native.
That's when Martin Best joined us.
I thought Martin's great, great tactic was,
"I'm not gonna complain directly to you
"about all these things, I'm just gonna pull in
"all the real users and all the real engineers
"and put 'em together in a room for three days."
And then after that, all the, you know, all the,
what should be done kind of falls out from like,
"Well, let's look at their problems."
we started getting these funny test cases,
that would be submitted to us,
that were megabytes large from Alon,
saying, "Hey, I compiled," and what sounded, at the time,
like ridiculous things, like, "Hey, I compiled SQLite.
Oh, and it crashes."
And we're like, "Why would you want to compile SQLite?
"And why is this thing so huge?
"Who'd ever wanna do this?"
Beause we didn't yet see the grand glory.
But we started to work more and more with Emscripten
and just get a feel for what, what sort of project was this,
what sort of JavaScript it emits?
Luke was the person who formalized
on the asm.js type structure,
and he did a really good job of recognizing
that this could actually be done,
that you could take the existing language
and embed within it a type system
for running low level code with high efficiency.
When I write this little bit of C, what does that produce?
And when I would look at it,
the realization all of a sudden set in
as, "This is great for the JIT, this is good code,
"that we can optimize well, but it's nothing
I'd wanna write by hand."
If I wrote this by hand, I would use objects
and they'd have to get garbage collected using properties,
but it's just taking all the memory
and putting into one giant typed array
and that's really efficient to index
and it's really efficient to get stuff out of it,
so this is actually good code.
We should optimize this type of code.
And that really led to asm.js, which was kind of
to formalize those concepts in a way
that really gives you as good a guarantee
as you can get in JavaScript.
Then at this point, we were seeing
that game engines just run pretty well,
that is, you're often more bound by
the speed of WebGL or web audio,
or some other feature of the Web platform,
than native code execution.
So then we went out to visit some game companies,
who treated us incredibly well
and they challenged us with, "Could you port our stuff?"
One thing that's really helped us in this space
is Jukka was just great at diving into their code bases
and finding out the issues, debugging corner cases,
so he just worked with them and fixed issue after issue.
And Jukka was our troubleshooter.
We kept testing it and out and looking for, you know,
critical flaws in the technology that would stop it
from really being able to deliver on this universal,
you know, dream of a VM.
People have tried to do this before,
and it's been very challenging.
But we just kept attempting to give it harder
and harder tests and it kept passing.
The challenge, of course, even from having
something that works is then having it distribute
to all the browsers.
And I have to say, it's been a remarkable diplomatic effort
between the groups and, you know, the other browsers
to come together and really make this thing happen.
You know, this entire train of development
that began with asm.js and now has led to WebAssembly
is to me, the ultimate culmination
of web development capabilities.
It's a new step in accessibility.
It's beyond anything achieved previously.
Being able to have your native application
directly running on the Web, it feels...
It feels like you're running something
that doesn't really, that shouldn't exist,
but it does, and you're able to do all the same things
that you were able to do in your native application
and that's just phenomenal.