Build the future of the web with WebAssembly and more (Google I/O ’18)


[MUSIC PLAYING] THOMAS NATTESTAD:
Hello, everyone. Is everyone hearing me? Hey. AUDIENCE: Hey. [APPLAUSE] THOMAS NATTESTAD:
My name is Thomas, and I’m the product manager for
V8 and WebAssembly on Chrome. This is my second
talk ever like this, but I’m really thinking it might
also end up being my last talk ever if the Google
Assistant gets any smarter than it already is. Right now, it’s
making phone calls and I feel like,
soon, it’ll end up doing all the talking for
us, which let’s be honest, is the real end
goal here anyways. Right? Well, anyways. I joined the WebAssembly
team a little while ago and, since then, I’ve been
learning more and more about WebAssembly and what
it enables on the web. And as I learned more,
I started getting more and more excited
about how it could change not only what we can
create on the web, but also how we create it. So what is WebAssembly anyways? Well, WebAssembly is a new
low-level binary format for the web. This means that it’s close
to the CPU machine code that your computer
understands, and it has all the security
that we’ve come to expect from executing code on the web. It’s compiled from
other languages, which means that you can
write something like C++, and then compile it
into WebAssembly. Because it’s so low-level and
compiled from other languages, it also offers
maximized performance. In this talk, I
want to talk to you about why WebAssembly is
such a game changer for how we create things on the web. Then I want to actually
jump into some code, and show you how you can be
writing WebAssembly today. Then I’ll showcase some of
the amazing applications that we’ve seen on the
web already utilize WebAssembly to great effect. And then I’ll close
out by showcasing a little bit of
what we still have on the roadmap for
WebAssembly features. OK. So what are the actual
advantages of WebAssembly, and why might you
want to use it? Well, first off is performance. Because WebAssembly
was designed for speed, it offers better performance
than JavaScript can. JavaScript is a
dynamic language, which is great to
making it easy to write, but it also means that
the JavaScript engine has to optimize that
JavaScript as it’s being executed on the page. WebAssembly is optimized before
it actually hits the browser, and this allows it to offer
better and more reliable performance than JavaScript. Secondly, WebAssembly
offers amazing portability. Because you can compile
from other languages, you can port not only your
own applications to the web, but also the incredible wealth
of C++ libraries and open source applications
that exist out there. And because C++ specifically is
supported on practically every platform, including
iOS and Android, you can now write C++ as
the common language across your different web and mobile
deployments by leveraging WebAssembly. Lastly, and potentially
most exciting to many of you out there, is the prospect
of more flexibility when writing for the
web, specifically the ability to write
in different languages. Since the web’s
inception, JavaScript has been the only
fully supported option for developers who want to
write logic for the web. But now, with WebAssembly,
you have more choice. The current fully supported
languages are C, C++ and Rust, but there are many
other languages that are experimenting with
adding support, including Kotlin and .NET,
both of which have shipped experimental support
for WebAssembly. So why do these powers and
abilities in WebAssembly actually matter in
the first place, and why do we want to do
interactivity on the web? Well, to really explain that,
I want to go back to a time when we didn’t have any
interactivity on the web whatsoever. This is the first-ever
web page, published by Tim Berners-Lee in 1991. As you can see, in
its original form, the web was really just
slightly formatted text meant only for consumption
of information. Aside from clicking
on links, there was literally nothing you
could interact with at all. Then JavaScript comes along,
and is famously created in a single 10-day hackathon. This brings some level of basic
code execution to the browser. And with this foundation
of JavaScript, we see the first real web
applications actually come to the web. These include
examples like Gmail, but also things like
MapQuest and eBay. As interest grew in what you
could do with interactivity on the web, we saw an
incredible explosion of developet-created libraries. And these were
libraries such as jQuery for doing DOM
manipulation, Angular and other popular frameworks
for organizing your page content on the client,
and also things like three.js and D3.js to
make beautiful and interactive visualizations. And there are so many
more other libraries that expand what we can
collectively create on the web. One of my favorite things about
working on the web platform is that you have this easy
ability for any developer to package up some functionality
that they are the expert on, and then share that
capability with everyone, allowing us to build amazing
things that we wouldn’t have been able to otherwise. Browsers also continued to
advance during this time. You had things like
V8 revolutionizing JavaScript performance to
expand what you could actually feasibly create with JavaScript. You also had capabilities,
like WebGL bringing interactive graphics, HTML5
bringing new capabilities to the DOM and, just
recently, with service workers allowing you to do
offline and so much more. All of these
technologies and others continue to expand
what was actually possible to do on the web. And the industry
responded in kind by bringing more and more of
their applications to the web. We saw examples like
Google Docs, Trello, and even Microsoft Office 365
all start to move to the web. But why? Why was there such an
appetite for application and interactivity on the
web in the first place? Why didn’t we just
leave interactivity to the native operating system,
where developers could have full access to everything and
choose whatever language they wanted to be developing in? Well, there are three
fundamental powers of the web that actually make it
a fantastic space specifically for applications. First off is linkability. This means that
your app is not only accessible by a single
click on any other page, but you can even
share your application or a specific document
for your application through a single shareable
clickable string. Secondly, the web
application is ephemeral. And this means that
your users don’t have to worry about the
process of going and installing your application, or whether
the application is trustworthy. The application is
securely delivered in a sandboxed environment
as soon as the user needs it. Lastly, the web is the only
truly universal platform, meaning that your application
is accessible by anyone on any device. This also means that you can
maintain a single code base and be sure that every user
can access your application– something I think all of
us can really appreciate. And so because of
these incredible powers that the web offers
for interactivity, we went from this small
scripting language all the way to this incredibly
powerful and popular platform filled with amazing
applications and capabilities, but which was still
fundamentally powered by the same scripting language
that was never really designed to do all of this
in the first place. That’s why the web browsers came
together to create WebAssembly, and it’s why WebAssembly
is now shipping in all four major browsers, making it the
first runtime since JavaScript was created more than
20 years ago to be shipped in every browser. WebAssembly isn’t meant to
replace JavaScript though. The two were designed
to interoperate. And within Chrome, it’s actually
the same team working on both. Rather, WebAssembly is
the foundational power that unlocks the
ability to create new native-like
experiences on the web, and it even gives
you a porting path to move your
applications to the web without having to rewrite them. OK. So hopefully that
gives you a little bit of a sense of what
WebAssembly can offer, and gets you as excited as
I am to jump into some code. I want to start off by
showcasing the final result of what you can actually build
right here at I/O by going and checking out the codelab
that we have available to you, or you can access it
from bit.ly/wasmio2018. And without further
ado, here it is. This is a hourglass
example where we’ve taken the chipmunk
physics engine, which is the one utilized by
Cocos2d, and then we’ve leveraged WebAssembly to
bring it into the browser. We used the engine to simulate
this running hourglass where every single grain of sand
that you see in the hourglass is actually its own
SVG DOM element. And if I want, I can
actually play with it. And you can see this
for yourself when you go and check out the code lab. But you can turn it over and
have all of the little SVG elements respond accordingly. OK. So let’s have a look at
some actual code and dig in. The first thing
I want to mention is WebAssembly’s amazing
toolchain, Emscripten. Some of you may know him
Emscripten from when it was used to turn C++ into
asm.js, which was a precursor to WebAssembly. Emscripten has since morphed
into a fantastic toolchain for WebAssembly. It’s what you’ll use
to compile your source file into the
WebAssembly format, but it also does so
much more for you. It offers a lot of
automatic translation, such as translating your OpenGL
API calls into their WebGL alternatives, and
it also simulates an entire file system for your
ported applications to utilize. It also includes the
C standard library, and provides
alternatives to Linux build tools, such as
configure and make. You can read all the
details about Emscripten at Emscripten.org. OK. So let’s look at some code. Here I have the
computational equivalent of a hello world,
which is a simple C function that calculates
the nth Fibonacci number. You’ll notice these two
additional pieces at the top. This top line is used to
include the Emscripten library, and then this second line
is used to tell Emscripten that we’re going to be
calling this function, and that it shouldn’t
remove this function even if it seems to be unused. This is the command that
we’ll use to actually compile our file, and we can step
through each of the pieces. You’ll first use emcc to
actually execute the Emscripten compiler. Then we’ll pass in -s WASM=1 to
make sure that Emscripten will output WebAssembly since
it still outputs asm.js by default, though this will
be changing to defaulting to WebAssembly soon. We also want to name
our output file, so we’ll pass in -0 fib.js. And then finally, we’ll pass
in our input file, fib.c. And this is the whole command
that you need to execute. emcc will then give us
back two different files, fib.wasm and fib.js. fib.wasm holds the
minimal WebAssembly binary for a Fibonacci
function, while fib.js holds some helper code to
load the WebAssembly module and set it up properly. It’s worth noting
here that Emscripten has many different ways
to output code based on your needs. In this example, we’re having
it output this js helper file, but you can even have
it output an entire HTML page with a terminal simulator
in it to help you get started. These are both useful
ways to get started, but they include some
code that might not be necessary in every application. And if you’re trying to
create something that’s truly production grade,
it will be important for you to dig into
the Emscripten library and documentation to
figure out what to include. All right. So next, let’s have a
look at the HTML page that you need to use in order
to actually include this. At the top line, we’ll just
use a simple script tag to import our fib.js. And including this
fib.js is what gives us access to this module object. The module object is a
central part of Emscripten, and it’s how you’ll access
Emscripten functionality. This module object
comes with a function called cwrap, which will return
a JavaScript function that allows us to call our
compiled WebAssembly function while taking care of
all of the input and output type conversion for us. And then we can actually just
call that function directly. And if we pass in
12, we correctly see that we get back out 233. Awesome. So this is a basic example
of how you can communicate between WebAssembly
and JavaScript, but there are also
other ways for you to communicate between
the border of JavaScript and WebAssembly. Which one you choose
will ultimately depend on your own preference
and the architecture of your application. All right. So for the next example, I want
to start off and show a brand new way of how you
can communicate between this JavaScript
and WebAssembly border. Our end goal will be
to make this animating, weirdly spinning ball painted
onto a canvas by utilizing some web APIs, but with
logic controlled in C++. So let’s start off, and
we’ll create a ball.cpp file. And you’ll notice,
once again, we include the Emscripten
library to get all the benefits that provides. Next, let’s talk about
this EM_JS function, which seems to have JavaScript
code inside of it despite this being a C++ file. Well, the reason
why we can do this is because EM_JS is a special
macro known by the Emscripten library. The format is that you first
pass in your return type, then the name of the function, and
then the list of arguments that you’ll be calling
that function with. The great advantage that EM_JS
gives is that you can now write the JavaScript that you know and
love while staying in that same C++ file. So in this piece of JavaScript,
we just simply find the canvas, wrap the context, and
paint a red circle at the given location
with a given radius. We then include a
classic main function that calls our function,
drawCircle, passing in the given
location and radius. Thanks to EM_JS,
Emscripten takes care of converting these inputs
into what will be used inside of the JavaScript
function, and then calling that JavaScript function. You can also find
more documentation on how EM_JS works
at Emscripten.org. All right. So this is the
command that we’re going to use to compile
this piece of code and, this time, we’re going
to get a little bit more fancy and optimized with it. We’ll pass in this -03, which
will tell the Emscripten compiler to optimize
aggressively, including the removal
of unused code. Because we’re telling Emscripten
to remove unused code, we also have to
explicitly tell Emscripten that we’re going to
want our old friend cwrap to still be included since
we’ll be utilizing that later. All right. Now we have, again,
an index.html file. Dirt simple this time. It just includes the
canvas tag, and then we load our ball.js script. You’ll notice that we don’t
actually have to call our main function at all, and this
is because we named it main, and Emscripten knows to
execute that on startup because it’s a
common C++ pattern. And boom, you put
all that together, and you have your single C++
file that calls a JavaScript function, and then paints
this ball onto the canvas. This is great. But so far, the only thing that
we’re actually doing in C++ logic is calling into
a JavaScript function. So let’s do something a
little bit more interesting. We want to start by
animating this ball. And in order to
animate it, we have to clear the canvas each frame. So we’ll just make
another EM_JS function. We’ll pass in void return
type, name and clear canvas, and no arguments. Inside of this, we’re just
grabbing the context again and clearing it completely. OK. So we want to actually start
taking advantage of some of this C++ logic
that we can implement, and we’ll start off
by including math.h. Because Emscripten includes
the C standard library, we get full interoperable
access to this math library without having to worry
about porting it ourselves. Then, further down
in our file, we’ll also have this static float t
in order to keep track of time, and we’ll swap out our main
function for an update function that we’ll be
calling repeatedly. Just like in our
last example, we’ll utilize EMSCRIPTEN_KEEPALIVE
to make sure that Emscripten doesn’t
get rid of this function, but you’ll also notice
that we have this extern C wrapper around our function. This is included so that
Emscripten won’t do any name mangling while compiling
our C++ function. The reason we didn’t have to do
this in the previous example is because that was
just C code not C++. Any C++ function whose name
you want to remain unchanged and referenceable from
JavaScript needs to be inside of this extern C wrapper. All right. And then inside
this inner logic, we just update
our time variable, call our clear canvas
function, and then draw a drawCircle function
with some funky sign math that we get from
the math library. Awesome. So now, let’s jump into
our index.html page, and actually set this up so
that we’ll call our update function on a continual basis. To do this, we’ll
once again take advantage of Emscripten
understanding what the module object is. We’ll define this module object. Then we set a pre-run
function on it. And this pre-run function simply
utilizes request animation frame to call our update
function that we, once again, get from cwrap. And then at the
bottom, we’ll also include our ball.js script. And just like that, you
have this wonderfully weird animation being
controlled by C++ logic. Great. So now that we know the basics
of writing some WebAssembly, let’s have a look at what
some developers have already accomplished by
utilizing WebAssembly. One company that’s
been able to utilize the performance of WebAssembly
and the linkability of the web is Figma. Figma is a powerful cloud-based
screen design platform that makes it easy for teams
to work in sync on a design through a single URL. Designers, product managers,
engineers, and others involved in the design process
can now iterate and design on a single place
to gather feedback, without having to worry about
exporting documents or managing the application. It’s all right there
instantaneously. It used to be that with
native design tools, you had to worry about
managing all of your files, whether everyone
involved in the process had the right
software installed, and whether or not people’s
operating system even supported the application
in the first place. Now you can use
the power of links as the single source of
truth, while enabling anyone on any device to
access your application or a specific document while
trusting that it will always be up to date. Great. So let’s have a look at how
they’ve actually architectured their application to
include WebAssembly, and see if we can
learn anything. From the nonperformant
part of their rendering, or of their application,
they use a modern TypeScript language with the
React framework. In the center area
of their application, they have a single canvas with
all of their logic implemented in C++ through WebAssembly. This section has three different
components inside of it. The first is a custom
rendering engine where they decode their file
format through WebAssembly, and then render it onto the
canvas by utilizing WebGL. Secondly is a
custom text editor, where they’ve actually been able
to utilize popular open source C++ library, again, by
leveraging WebAssembly. And then finally, they
have a collaboration system that uses web sockets for
fast multi-player editing. By utilizing all of these
different advanced tools and features of the web, they’re
able to create an application experience that is not
only highly performant, but also has all of
the advantages of being an application on the web. Another great
company that I want to talk about that’s really
been able to leverage the universality and
ephemeralness of the web is Construct 3. Construct 3 is a full-blown
game engine and editor that allows you to
create and export games directly from the browser. Thanks to the ephemeralness,
they have an onboarding flow that takes you from
their marketing page, loads up the editor,
lets you pick the project and be inside of the application
in less than a minute. Once you’re in the application,
you can immediately jump in and start making
any edits that you want, maybe adding a little
bit of game logic or doing whatever other
edits you need to. And then when you’re ready,
you can also export it directly from inside of the browser. This is an interesting
point, because here’s where Construct 3 leverages
the universality of support for the web platform by
enabling their export to different platforms. It actually exports the
game as a single web page, and then utilizes basic
wrappers around that content to make it appear like
a native application. Construct has all of
their UI and logic implemented in
JavaScript, but utilizes WebAssembly for
its audio decoding, as well as poly
filling functionality in some older browsers. All right. Another company that I’d like
to tell you about is AutoCAD, but instead of me
telling you about it, I’d like to invite
Marcus O’Brien onto the stage, senior product
line manager at AutoCAD, to tell you about the
experience himself. MARCUS O’BRIEN: Thanks, Thomas. That’s great. [APPLAUSE] Hey, everyone. How’s it going? So my name is Marcus O’Brien,
and I lead the AutoCAD product management team at Autodesk. So we have a couple of people
from AutoCAD in the audience here today, and I’d
like to give a shout out to the web team and the mobile
team that’s come from Tel Aviv specifically for Google I/O. So today, I’d like to tell a
short story about AutoCAD’s journey to the web. So AutoCAD is a
computet-aided design and drafting
software application. It’s used by the world’s
most innovative engineers and architects to
imagine, design, and make the world around us. It was first released in 1982. It’s not a new application. And prior to AutoCAD,
design was done by people using pen and
paper on drafting boards. The cost of revision
was slow, and innovation was slow as a result. So
the vision for AutoCAD, from the very beginning, was
to reduce the amount of time it takes to
innovate, to increase the number of iterations
possible within a design process, and to
ultimately help designers optimize for the best possible
solution to the problems they were trying to solve. And AutoCAD has changed
the world continuously as it’s evolved over
the last 35 years. More than 10 years ago, or more
than 10 years after AutoCAD was first introduced,
the internet was born. We heard Sir Tim
Berners-Lee pioneered this. And AutoCAD was made popular
with Mosaic and Netscape and Internet Explorer. AutoCAD first dipped
its toe in the water of internet connectivity
with AutoCAD 2000I, where I stood for internet. And many years later, we first
released in 2010 the AutoCAD web and mobile apps,
but really this was just the beginning of
the AutoCAD connected story. So now with AutoCAD on
desktop, web, and mobile, a new vision was born. This was a vision
where we could free our customers, these
designers, from their desks so that they could take AutoCAD
wherever they go with them to increase their chances
at innovating even further, and to add to the workflows. So the AutoCAD web
app was intended to allow people to work from
anytime, anywhere, and have access to this
precision drafting app, whether they’re at
home or on the go. I just want to tell you
that AutoCAD’s standard file type is called the DWG file. There are an estimated 2 to 5
million DWG files open today. That’s a lot. And there’s some 5 billion
DWGs on cloud servers today. So the anytime, anywhere
access is even more important than it’s ever been before. However, as much as we wanted
to bring AutoCAD to a browser, we were a little bit
limited by the technology that was available at the time. In 2010, we released
a flash-based version, which got us kind of
a toe in the water, in terms of having a
basic editor in a browser. In 2014, we shifted from
flash and changed to HTML5 and JavaScript. And this worked, but we realized
very quickly that this was not a very scalable way for us to
build this precision drafting tool in a browser because we
had all the features already in our C++ code base, and we
were having to rewrite them in JavaScript for this browser. So it wasn’t very scalable. So two years ago,
we started exploring what were the options for
us to port our common code base to the browser, and we
got a number of quick wins early on. So we started to take
it more seriously. And the wins kept coming. So one year ago, we were able
to release our first beta viewer to our beta customers,
where they could view or read native DWGs in a browser. So to put that into
context, customers were able to open a
25-year-old drawing file and read it in the browser. About eight months ago,
we were able to port our first true feature
from AutoCAD core over to our browser. In December, we had the makings
of a basic editor with lines, arcs, and circles
on WebAssembly, and we released this in beta,
as well, to our customers. And then on March 22 of this
year, we hit a major milestone. For the first time, we were able
to release the AutoCAD web app, and we were finally able to
unlock the power of AutoCAD in a browser with zero
download and install required. So how did we make this happen? We have the common
AutoCAD C++ code base, which we translate
with Emscripten, which gets compiled at
runtime in the browser. We have our React and TypeScript
UI running on the main thread, and it works together with
WebAssembly modules running on a web worker to create
the AutoCAD web application. But what does this really
mean in real terms? So having a shared common C++
codebase means that our C++ developers can develop
features and bug fixes across our platforms without ever
having to learn JavaScript or other web technologies. And for our customers,
it means that they have enhanced cohesive experiences. The feature that you build on
desktop, it just works on web. So here’s a look at
it running in Chrome. You might have seen this
on main stage yesterday. So customers
familiar with AutoCAD will immediately recognize this. You can see in the canvas
here, it’s very familiar, and you can see that
you’ve got your crosshairs. It’s a very AutoCAD experience. And interacting with it feels
like using AutoCAD desktop. You can see the JavaScript UI
is giving very user feedback and control to the user, and
it’s interacting smoothly with the performant WebAssembly
canvas that’s been ported from our C++ codebase. So overall, building
on WebAssembly helped us lock deeper
capabilities of our AutoCAD’s optimized code base that would
have been impossible to rewrite in JavaScript. It cuts our development
by orders of magnitude, and in fact, it’s
more performant than had we developed
this in JavaScript alone. So with AutoCAD running on
WebAssembly, in addition to our AutoCAD core codebase,
our vision for a web app is no longer limited
by web technology. So I’m really
excited about where we’re taking this
and the opportunities that we’re pursuing, both for
AutoCAD and for our customers, in terms of what they can do
with AutoCAD in a browser. And with that, I’d like to
hand it back over to Thomas. Thanks very much. [APPLAUSE] THOMAS NATTESTAD: Great job. Thank you, Marcus. It’s been really amazing to
see AutoCAD utilize WebAssembly to gain all the powers of the
web, and enable their customers to access AutoCAD anywhere. So now that we’ve seen some of
these different amazing, high performance demanding
applications, I want to go back and talk
again about libraries. Remembering back to the
early stages of the web when we saw that explosion
of amazing developer-created libraries, I think we’re at
a similar infection point now with WebAssembly. Well, I don’t have time to
show off all the examples, unfortunately. We’ve seen some amazing
developers leverage WebAssembly to make everything from physics
engines, facial recognition systems, video editing, and
even artificial intelligence. These tools can be packaged
up, and then enable all of us to have these capabilities
for ourselves. And I’m so excited
to see what all of us will be able to
build when we unlock these new next
generation libraries that are enabled by WebAssembly. We’ve also seen existing
popular libraries start to adopt WebAssembly to
maximize their performance. We’ve seen the Glimmer
rendering engine, which is the one utilized by
the Ember framework, already start making commits
with WebAssembly to improve their performance. OK. So now that we’ve seen some
cool use cases for WebAssembly, learned a little bit of
WebAssembly ourselves, I want to show off what we
still have in the works. This is some in progress
works, so it’s not completely refined yet,
something that I think will come across in the
style of these slides. Probably the most exciting
feature that we’re working on is Threads, which can double or
even quadruple the performance of your application. Modern CPUs ship
with several cores, but historically, the web
has had very limited access to these additional
cores, restricting how performant your application
could be compared to native. You get some additional
access to these cores through web workers,
which are great, but workers can be
quite heavy weight, and they only communicate
through post message, restricting what use
cases they enable. The way WebAssembly
threads will work is by using shared array
buffer to communicate between the workers
at high speed. This also means that existing
C++ codebases that utilize P threads, or which
rely on blocking, can be ported directly to the
web and take full advantage of the benefits that
threading provides. We’re also improving the way
that WebAssembly can talk to the rest of the web browser. Right now, WebAssembly
always sits within a sea of JavaScript. And when it wants to make calls
to the DOM or to web APIs, like WebGL, it has to go
through JavaScript to do so. We’re changing that so that
WebAssembly can directly hold references to
the DOM or web APIs, and communicate without having
to go through JavaScript. Looking a bit
further ahead, we’ve also started exploring direct ES
module support for WebAssembly. This will improve the ability
for JavaScript and WebAssembly to import and interact with
modules of the other type without having to do any
unnecessary wrapping. Together with letting
WebAssembly hold references to the DOM and web APIs,
we’re substantially improving WebAssembly’s
interoperability with the rest of the web stack. Also further out is the prospect
of adding first-class support for other languages. The reason why C, C++, and Rust
are the current fully supported languages is that they manage
their own memory and don’t have a garbage collection system
that manages it for them. As I mentioned earlier, we
have seen languages like Kotlin or the .NET framework
ship experimental support for WebAssembly. And they’ve been able
to accomplish this by actually compiling down their
garbage collector and the rest of their runtime
environment to WebAssembly, and then shipping it
along with their page. Because of WebAssembly’s
small size, this doesn’t add as much
bloat as you might think, but it’s definitely not ideal. And you also have
to be very careful when making interactions
with the DOM or with web APIs to prevent you
from leaking memory. We’re working on a proposal
called the Managed Object Proposal that we hope will
add better first party support to these languages
and enable them fully in the browser. So that brings me towards
the end of my talk. And to close out, I want to
really just ask all of you to go out there and
build amazing things with WebAssembly. Go port some
application to the web. Go create some amazing
developer library that will give all of us
additional super powers on the web. Whatever you do, and
whatever you end up creating, I hope you’ll share
it with others. I would certainly
love to hear about it, and you can tweet me directly,
or you can tweet the awesome V8 team that’s actually
working on all of this functionality @VHAS. Thank you so much. [APPLAUSE] [MUSIC PLAYING]

54 thoughts on “Build the future of the web with WebAssembly and more (Google I/O ’18)

  1. <sees ball.cpp doing javascript in C++>

    Now… What if I DON'T want to write javascript to draw stuff on the screen…?

  2. Amazing!! Wasm looks very promising… During the the wohle talk I had the feeling that Java was left out on purpose. C++, Rust, Kotlin… no word about Java 😉

  3. <annoying_pedant>
    The "#include <math.h>" is still C and not C++, the "#include <cmath>" should be used when you're talking about C++.
    What makes this code be C++ is compiler that takes it as C++ input probably because of "cpp" extension.
    </annoying_pedant>

  4. I have few points to flag:
    Web assembly is not faster because it is complied from non-JS languages. its faster because its more low level
    And, If JavaScript is able to scale from simple text based apps of late 90s to complex apps of now a days, I dont think we need new technology. The language is successful in handling anything. Mark my words, 20 years down the line, you will use JS…
    And, I am sure some day people would prefer to compile WebAssembly from JS ….

  5. Just a thought. Why not allow/upgrade the JS compilers(V8) to output a binary file of the parsed js. Then one would get the load time speed benefits out the box, with out many hurdles, implement another extension, or just have a new global function that if called, assumes the remain file is all binary. Would be nice to be able to have different file extension, so one can hot compile the parse stage on the server to the required browser v8 versions and then cache the output. In the same way http request headers, specify the accepted transfer support encoding, one add the v8 engine supported version in the request. One could actually use the request headers only and not even need to implement a new file extension. This then also would work well with edge compute, were the edge nodes would perform the caching and compiling of parsed v8 resources. The main end point, need only server js and not have to worry about handling the load when their updates to v8 engine, browsers. Maintain of all front-end(endpoint) js code, would be done by all the caching servers, simplifying deployment, as one no longer need to deploy all versions of binary formate to the support the role out of ever green browsers, or wait for mass role out of compiler updates to browsers, before worth update the server frontend, endpoints. The only complexity that is going to arise probably is from tree shaking and shared code, in which case a backwards compatible loader function from js would be need to bind and pass information about memory spaces allocations. Still end up with on ambiquitius language then, but don't loose all compiler optermization for hot code.

  6. If Apple and Microsoft abandoned WebAssembly that will be the time I start using all Google products.

  7. JavaScript is awesome but isn't meant to do what the developers these days are pushing it to do that's why you see browsers using so much resources it's mostly JavaScript codes i would love to see JavaScript keep growing but only in what it was meant to simple interactivity and not building an entire 3d video game based on it or whatever some crazy developers are doing these days

  8. I always think that why is it so hard for Google to create simple solutions..it is always simple things done most complicated way.
    Maybe there is just too many smart people competing these things..

  9. WA is super awesome. Closing the gap between native… Nice! Not too long into the future before we run AAA 3d games at 120fps in a browser 😉 Wishful thinking?

  10. 14:13 "You can now write the javascript that you know and love while staying in that same c++ file."
    ….
    ……..
    Ok, I'm going to say this slowly and try to be as concise as possible.
    1. The less mandatory javascript in the pipeline, the better. Ideally none. If JS doesn't need to be intimately linked with wasm, why is it? I understand where you are coming from with calling C/C++ code from javascript, not a bad idea, a page out of python's playbook, and a wise decision if you want to keep JS healthy for the foreseeable future. Personally I don't really want to deal with JS any more than I have to.
    2. The garbage collector, my gut says keep it out of the wasm spec entirely. I know you will likely include one that you think will work great for your purposes but I guarantee that some other lang/langs compiling to wasm will have a different way of thinking about memory management and they will have to include their own anyway. Perhaps people will want to choose to use a different garbage collector algorithm when they compile because of how their particular program performs with one over another.
    3. If you don't go through with #2 and do include a GC, let me turn it off, or at the very least don't turn it on unless I request to use it. I don't want some GC running in the background checking to see if it can free memory that I am managing manually.

    I am very much pro choice when it comes to what languages people decide to use. I know your attitude is that "WASM will not replace JS", but can we not have a choice of what language we use in our tool chain? Is it really necessary that javascript be in the equation at all to get the wasm into the browser? (In short, I do not see wasm and JS inter-operation as a positive, or at least I am highly skeptical that it will not result in a negative.)

    I do know javascript, however, if given a choice between the words "love" and "loath" to describe my feelings for the language, the point on that line would lay far far closer to the latter than the former. I am clearly biased, make no mistake about it. And I will say it again like thus: javascript killed a part of my soul, and I would not hesitate to throw the power switch on the world's last NodeJS deployment.
    I am clearly not your intended audience. Oh well.. take it or leave it. I do know many that would hold similar sentiment though. I am not too terribly broken, my faith in web standards was never strong to begin with.

  11. Microsoft is leveraging Web Assembly to run a Mono based C# web framework in the browser. The project is called "Blazor". It's really cool, you should all check out their Github.

  12. Unless they come up with something that directly manipulates DOM, js will still rule. Blazor has a js interop. This is not great. Why not let a strongly typed language like C#, that compiles natively, directly interacts with DOM and runs in the browser replace js completely. Anything else is a half-baked solution, not worth wasting time over.

  13. Everybody speaks about Web AssIembly, but its C++/rust which is promoted. Well, would be cool to compile JS in to Wasp 😉 (since everybody knows JS, right?)

  14. WebAssembly is promising, but it is still not good. It is still slower than JVM or .NET VM (i.e. Mono), and slower than native C++. It lacks optimizations, good in browser optimizing compiler, very low overhead memory operations, SIMD and multithreading. There are many benchmarks on the web where WebAssembly is still 30 times slower than native C++ app, even if the app is mostly CPU bound (no io, no syscalls, no javascript calls, etc).

    It still bad.

  15. I'll make a tour tomorrow as things change fast in 6 months . But this video made me sad when dealing with that enscriptem stuff. I'll jump on the train when go or another pleasant functional language has full support and the binary has better access to the Dom. Right now I feel it has very limited uses, I'm even surprised about the perf gain with all the bloating.

  16. I love the idea of WA it is gonna really change the game for the web and it will make progressive web apps even more powerful

  17. Awesome but its one step closer to server based os's and software that you "rent" monthly and don't ever own. The "money grab" implications of this are huge. Its also a way to end software piracy which is a good thing but I can see the big software corps bleeding the users dry as well.

  18. Wouldn't it be simpler just to release a new JS version with static typed functions (and variables) ? This way the VM could compile the function you need to be fast to native code…

  19. It's not actual Assembly since it's not being assembled into machine code. The browser still has to compile WA into real Assembly per-platform, in which case, why is this better than JavaScript?

  20. I dont think it's gonna change anything for developers, even now as we speak people use different stacks for web developing:js, php, ruby etc. And there are jobs for all of them 😀 also since WA is not a language itself and other languages have to be compiled to WA, who says u cant write JS codes and compile them into WA which itself has to be compile into real assembly 😀

  21. Screen-rendering "open-GL"-style might be interesting for high-performance DOMs. If it is, i'm gonna go for Mono and C#, I've grown tired of Oracle and their Java license versioning-nonsense. .Net Core is too tempting to not deserve a good try.

Leave a Reply

Your email address will not be published. Required fields are marked *