
Compiling to WebAssembly: It’s Happening - mnemonik
https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/
======
c0nfused
Web assembly always makes me a little sad. It feels like we are going back to
flash only it won't be bad this time, I promise, no really.

I always feel like the most obvious use for it is to start writing truly
hateful and abusive code.

I'm sure this is because I'm getting old.

~~~
kristopolous
We will eventually come to terms with the fact that Flash was 15 years ahead
of everything else on multiple fronts and we ought to have been just chastised
the terrible developers doing awful and horrendous things with pretty
technically sound software.

~~~
Scaevolus
HTML5 _still_ isn't able to deliver the quality interactive experiences
(Games) without applying a lot more effort. Even "simple" things like cross-
browser low-latency sound effects are still difficult.

Flash presents a single platform with a single vendor that can innovate as
quickly as they like. The web platform is inevitably cumbersome and slow in
comparison -- over a decade later they're still playing catch-up.

I'm looking forward to WebGL ads that eat battery life with excessive shaders.

~~~
kristopolous
As a strong supporter of open source, doing a comparative analysis of HTML5
and Flash, I have to admit that private enterprise was able to kick the ball
forward so much faster here ...

I remember watching a vector animation version of a "tell-tale heart" in flash
in 1998. On a 28.8 connection it played smoothly full-screen on a 120mhz
pentium with 16mb of ram. I remember clicking the play button and having it
just miraculously starting to play without any wait, streaming down and
uncompressing in real time. I was floored by it. 12 years later I was invited
to watch a spiderman animation demo using HTML5 ... there was a 30 second load
time, the framerate was probably 1fps, the audio didn't work, the content
didn't render properly ...

It's like how Microsoft was able to pull off nearly everything we could do
today by shoe-horning their activeX technology into ie3. Just load a bunch of
cab files and drop them into the page like OLE components and bam, you got
just about everything. The interactivity could bootstrap - that is, not need
any extra plugin and you could engage with the other content on the site using
vbscript or javascript interfaces in a two-way manner. It was pretty nice.

Netscape retorted with their JVM integration but it just wasn't the same ...

~~~
DanWaterworth
If you want to go fast, you go alone. If you want to go far, you go together.

------
klodolph
This seems like the modern trend, and I like it. I'm going to compare this to
the recent developments with OpenGL and Vulkan. With OpenGL, you ship textual
source code for your shaders written in GLSL, and you have to hope that the
compiler on your client's machine does the right thing! With Vulkan and
SPIR-V, the compiler is taken out of the equation, and you can use whatever
language you want to write shaders, validate them ahead of time, and ship the
validated binary blobs to the client. Incidentally, I'm looking forward to
WebGL 2. I really miss being able to use texture arrays, integers, and
instancing.

------
andrewchambers
Web browsers are turning into giant, poorly designed operating systems. My
current operating system can already run binaries, this is reinventing the
wheel in a massively over engineered way.

~~~
gnuvince
And I don't understand why. Take the two most popular mobile platforms, iOS
and Android: people there routinely download and install new applications and
typically never interact with Facebook, Twitter, Gmail or Instagram via their
browsers. Why should the situation be different on the desktop? I feel that
the efforts should not be going into making the browser into an OS that can
run general-purpose software, but rather getting a packaging system that is
cross-platform and easy for users to use. My own preference would be something
based off of Nix so that you can avoid many problems related to library
versions and whatnot, but anything where a user could be pretty much
guaranteed that if he clicks "install", he'll be able to use his application
in the next couple of minutes.

~~~
pcwalton
> Why should the situation be different on the desktop? I feel that the
> efforts should not be going into making the browser into an OS that can run
> general-purpose software, but rather getting a packaging system that is
> cross-platform and easy for users to use.

Cross platform is a red herring. The iOS and Android app stores are not cross
platform. Ease of use is also increasingly a red herring. The Windows and Mac
app stores have been around for a long time and are quite easy to use. Yet
they have not ushered in a shift away from Web apps on the desktop.

I think we should be looking at why Web apps have been successful on the
desktop rather than pretending they have no advantages.

~~~
andrewchambers
> I think we should be looking at why Web apps have been successful on the
> desktop rather than pretending they have no advantages.

I think there is a perception of "try before you buy" with web apps that is
appealing. Even when apps/programs are free, you feel like you are giving
something away by installing them.

------
wilg
In the recent press tour about Swift, Apple seems to be really gung-ho about
people using Swift everywhere.

Since Swift is built on LLVM and there's direct LLVM support for WebAssembly,
I wonder if Apple will get behind WebAssembly so they can get Swift in the
browser.

~~~
bobajeff
If I'm not mistaken Webkit is implementing experimental WebAssembly support.
It appears to be the only implementation being worked on upstream out of all
the major browser engines right now.

------
jacobolus
Is there (or are there any plans to add) a WebAssembly -> asm.js compiler, so
that I can write some code by hand in WebAssembly and still get it to run fast
in old browsers? Or are there features of WebAssembly that would be impossible
to add in asm.js?

The reason I ask is that asm.js is really painful and cumbersome to write by
hand and wasm seems substantially nicer, but I only have small bits of
numerical hot loops which I want to use wasm/asm.js for, and I have no desire
to bring a bunch of code written in C into my little project.

~~~
erickt
Yes there is. That's the wasm2asm project Alon mentioned in the post.

~~~
jacobolus
Whoops, I read right past that line. :-) Thanks, I’ll take a look.

For anyone interested, the code is in wasm2asm.h:
[https://github.com/WebAssembly/binaryen/blob/master/src/wasm...](https://github.com/WebAssembly/binaryen/blob/master/src/wasm2asm.h)

------
kalsk
This sounds like an odd question, but I honestly need somebody to explain this
to me...what is the motivation behind the modern trend to put _everything_ on
the web? Is there something you get by running your program from a browser
that you don't get from downloading and running an elf or a text file, or is
this entire trend based around appealing to users who don't actually know how
to use their computers?

~~~
1ris
It's the current fad. But nothing new. Since the beginning of computing the
tides go from thin-clients and fat-clients back and forth. Currently fat-
clients are en-vouge.

~~~
sangnoir
And here I was thinking (mobile) apps were the current fad.

------
vvanders
Exciting stuff. Just further solidifies in my mind that C/C++ is one of the
few languages that will run _everywhere_.

------
wilg
Does code written in WebAssembly have access to the DOM somehow? How will that
work?

~~~
Klathmon
In the current proposal there is no way for WebAssembly to directly access the
DOM (or any other "Web API" objects).

Basically you will need to drop back down into javascript and handle that
there (basically how asm.js does it now).

But there is a proposal to eventually integrate direct DOM access into Web
Assembly, but that's for after they get it up and running.

~~~
mozumder
If they wanted to do it right, then an HTTP requests itself should serve a
compiled HTML binary based on an AST. The binary version of HTML.

~~~
jcfrei
I would consider that the worst scenario. If each website was its own binary
application it would undo the open source aspect of websites (even though
that's only partly true today due to all the obscured javascript). But maybe
that would actually be desirable for all companies which rely on advertising
revenue and want to prevent any modification of their web content (such as
removal of ads). It'll be interesting to see how the web develops in the
future. WebAssembly definitely seems to give more control to the author.

~~~
mozumder
Just because it's a binary AST doesn't mean it's closed.

------
eecks
WebAssembly lets people write in C++, Ruby, Python, etc and for that code to
work in the browser like Javascript does at the moment. Am I correct?

~~~
azakai
Mostly. The initial target is C++ and similar languages, and it will not have
DOM access, but using suitable libraries (libc, SDL, etc., for example
emscripten's) you can write a normal C++ program and have it run in the
browser.

You can also run Ruby and Python in the browser by just compiling their C or
C++ VMs. But that won't still work "like JavaScript" \- their objects won't be
native VM objects in the browser, it won't use the browser's GC, they won't be
observable in the browser's debugger, etc.

So far all of that was already possible, and done, with asm.js.

In the future, it is a goal to work to do GC object integration, so that
something like Ruby or Python could actually compile down to something with
native VM objects, and that would also allow calling DOM APIs directly. (This
will likely still require a compiled VM, though.)

~~~
discreteevent
Its worth pointing out that it would hardly be practical to expect users to
download the code for the entire Ruby VM (and libraries) when they visit your
web page.

~~~
Eridrus
Depends how you look at it.

If you're using a web _page_ that is mostly just a CRUD app, sure, no-one will
wait around for that, but if you're shipping a version of IPython that can run
in the browser, I think people would be pretty happy about it as long as the
blob can be cached and hopefully shared between sites since it's on a shared
CDN.

~~~
azakai
I think you're right. While downloading a VM doesn't make sense for a small
site, for many cases it could. There are also fairly compact VMs for some
languages. And WebAssembly will make the VM download substantially smaller.

------
saosebastiao
Does anybody know if there are plans for an API for garbage collection? The
WASM spec as it currently exists seems to be only useful for non-GC languages,
and it would be a shame if we ended up shipping a new GC implementation for
every page that we load. Perhaps something that would allow compilers to tap
into the native JS GC?

~~~
swolchok
What would the GC scan? What do pointers look like? At the assembly layer, you
have the flexibility to not have a C runtime (and therefore no C stack), and
you might be doing fun things like having tagged pointers that the GC would
have to know about.

In short, the WASM layer is IMO the wrong layer for GC. I think the closest-
layered applicable solution is caching & pinning guarantees for common
libraries, which may already be addressed by the same solutions for common JS
libraries (use a common CDN & let the browser caching keep it pinned).

~~~
icebraining
The GC would scan whatever the program told it to scan, by using its API, like
the Boehm GC library:
[https://en.wikipedia.org/wiki/Boehm_garbage_collector](https://en.wikipedia.org/wiki/Boehm_garbage_collector)

I think it only makes sense, seeing as interaction with the native JS VM will
be inevitable for a long time.

~~~
Arelius
Perhaps then you should just use the Boehm GC library then.

------
jokoon
So does it just do what NaCL was already doing, or at least is the objective
the same?

I'm more worried about more specific things like hardware access (GPU, mouse
inputs, networking, windowing)

It seems wasm runs at native speeds and take full advantage of optimization,
but can it really be a solution fits all? There must be some things wasm can't
do. And so far, since JS did almost everything, I don't see the point of wasm
if it can't do what other language can.

~~~
azakai
The main difference is that NaCl used a plugin API (PPAPI). WebAssembly, like
asm.js, can access JavaScript, and so it has indirect access to DOM APIs, with
no new powers over the existing web.

The main point of wasm, from my perspective, is startup speed. wasm will allow
much smaller downloads of large codebases, and much faster parsing (due to the
binary format). For small programs this might not matter, but for big ones,
it's a huge deal.

------
tevlon84
Hi Alon,

thank you for sharing. I am a Computer Science Master student and i would like
to contribute to the development. The git looks really full and i don`t know
where to start.

~~~
azakai
Which area were you interested to contribute to?

For Binaryen specifically, this bug could be a good starting point:
[https://github.com/WebAssembly/binaryen/issues/2](https://github.com/WebAssembly/binaryen/issues/2)

Other issues in the tracker there as well.

Bigger topics are to make progress on wasm2asm, and to start an implementation
of the current binary format (link is in the design repo), which Binaryen
needs to support.

~~~
tevlon84
ok. Thanks, i'll have a look.

------
n00b101
So the current toolchain involves using emscripten to generate asm.js and then
using binaryen to convert asm.js to WebAssembly. Unfortunately emscripten
depends on a fork of LLVM (FastComp), with no plans for a proper LLVM asm.js
backend.

Are there plans for a properly WebAssembly LLVM backend that does not depend
on forking LLVM (like emscripten)?

~~~
sunfish
Yes: [http://llvm.org/viewvc/llvm-
project/llvm/trunk/lib/Target/We...](http://llvm.org/viewvc/llvm-
project/llvm/trunk/lib/Target/WebAssembly/)

------
geon
Is there any progress on making the compilers utilize the js gc instead of
including their own entire runtime?

~~~
kevingadd
This is largely blocked by the ecmascript committee's incredible slowness in
introducing key features like Weak References, but it will happen eventually.

------
tuyguntn
Does this mean anyone can write Python to wasm converter then run it on
browser, looks like LLVM backend?

~~~
klodolph
Someone could write a "PyWasm". You could then ship your Python code as a wasm
blob, but you'd have to include all of the standard library parts which you
use, which are probably significant. The library could be a separate resource,
so clients can cache it separately.

------
shurcooL
I'm very interested in compiling Go to WebAssembly. Based on what I read, it
seems that so far you can primarily try it with C/C++ code.

If one were to build a Go -> WebAssembly compiler, what are good routes to
take? I can see there's going to be multiple possibilities.

~~~
frame_perfect
Will be a huge pain in the ass. Go's compiler uses Plan 9, and WebAssembly
uses LLVM.

~~~
adrusi
There is llgo[1] which is an implementation of go on top of the llvm
toolchain.

But if I'm not mistaken, WebAssembly won't accept just any llvm bitcode. It's
similar to how emscripten will work with the bitcode that clang outputs, but
not other llvm compilers like rust or ghc.

[1]: [http://llvm.org/svn/llvm-
project/llgo/trunk/README.TXT](http://llvm.org/svn/llvm-
project/llgo/trunk/README.TXT)

------
exabrial
Cool, but why not just use, you know, Java bytecode? Existing toolchains,
compilers, runtimes, virtual machines could all be reused I'm sure. Actually
there are a hundred different great virtual machines that could be used...
Why, yet, another?

~~~
stephen_g
All the compiler backend/code generation is using LLVM, and the VMs are all
pre-existing (JavaScript with some extensions), so there is a huge amount of
existing code being used here.

------
hDeraj
I see WebAssembly this way:

WebAssembly is to JavaScript what WebGL is to Canvas

------
iandanforth
My experience is that the barrier to entry for JavaScript is not that it's a
new language, but that you have to learn async thinking and are restricted to
a single thread.

Does WebAssembly address either of those points?

~~~
amelius
Regarding threads, I don't think so. And even if they would address threads,
then there's still the problem of a shared address space between threads to be
solved, and the implementation of mutexes, etc.

------
currentoor
I'm hoping for a day where I get two threads in my JS runtime. Now that would
be nice...

------
ajarmst
I'm sorry, but I'm not following. What's the problem this is supposed to
solve?

------
al2o3cr
WebAssembly sounds interesting, you could use it to write little apps that
embed into a page.

And call them "applets". Nobody's ever done that before, right? :trollface:

------
mei0Iesh
Finally! Maybe now someone can build a web app that enhances the reading and
discover of documents. Each browser could be a repository of text files, each
with an address, so you can have words in the text pointing to another
document's address.

------
yoavm
I suspect too many web applications are going use WebAssembly to obscure their
code and the way they work, thus making it impossible to learn by studying
their code. As someone who learned programming mostly by looking at other
people's code, I'm afraid the web will change in a way that would make it a
lot harder to do so.

~~~
icholy
Do you really read other people's minified/obfuscated js?

~~~
yoavm
It was far less common to minify JS code when I started doing that, but yeah,
even now I much rather have minified JS code than no code at all.

~~~
MichaelGG
So decompile or disassemble WebAssembly?

------
etiene
YES YES YES!!! OMG! THANK YOU <3 <3 <3 I've been waiting so long for this!
Maybe my dream of running native Lua on the browser will come true? Will I
already be able to run Lua's interpreter now? :D :D Gonna look deeper into
this as soon as I have time, omg so excited <3

~~~
corysama
The Lua interpreter was one of the earliest test cases for the C++ to JS
compiler.

[https://kripken.github.io/lua.vm.js/lua.vm.js.html](https://kripken.github.io/lua.vm.js/lua.vm.js.html)

~~~
etiene
ohh!! I know this project! I thought it had nothing to do with web assembly,
thank you for the heads up

