
Experimental support for WebAssembly in V8 - AndrewDucker
http://v8project.blogspot.com/2016/03/experimental-support-for-webassembly.html
======
sunfish
The big news here is coordinated announcements from _multiple_ browsers:

[https://blogs.windows.com/msedgedev/2016/03/15/previewing-
we...](https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-
experiments/) [https://v8project.blogspot.com/2016/03/experimental-
support-...](https://v8project.blogspot.com/2016/03/experimental-support-for-
webassembly.html) [https://hacks.mozilla.org/2016/03/a-webassembly-
milestone/](https://hacks.mozilla.org/2016/03/a-webassembly-milestone/)

introducing support for the live demo:

[https://webassembly.github.io/demo/](https://webassembly.github.io/demo/)

~~~
espadrine
A WebKit announcement is notably missing, unfortunately. However, it is great
to see Edge, even though it is not a surprise, as they have been pushing for
WebAssembly from the start.

~~~
sunfish
WebAssembly is "In Development" on WebKit's status page:
[https://webkit.org/status/#specification-
webassembly](https://webkit.org/status/#specification-webassembly)

~~~
jacobolus
Also cf.
[https://bugs.webkit.org/show_bug.cgi?id=146064](https://bugs.webkit.org/show_bug.cgi?id=146064)

------
titzer
Standard caveats apply here. It's experimental: a couple bugfixes are already
in flight and we're working hard on improving the startup time.

Overall a huge thanks to our friends at Mozilla and Microsoft and Apple, with
whom we've worked closely with over the past year to make this a reality.

------
xigency
Finally, a reason to go into JavaScript development with a background in
compilers! I can see the need for cross-compiling tools and certain special
skills for performant web development in the future, especially since even
with complete adoption of WebAssembly this will still create a split between
browsers that support it and browsers that don't.

From glossing over the wasm spec, it seems it's designed for C++ compilation,
which in the environment I do development, is totally impractical. It sounds
like a TypeScript to WebAssembly compiler isn't on Microsoft's radar. In that
case, it might be time to work on some tools for analyzing syntax and start
annotating types, because compiling from ECMAScript to WebAssembly would be a
great boon in production.

~~~
geon
Why on earth would you want to compile javascript (which is what typescript
essentially is) to wasm?

~~~
nfriedly
If nothing else, it results in a smaller download than minified js. (I believe
that's true even today.) And, in theory, it should be able to run a bit faster
also. Not sure if that one's true yet.

Update: Here's a quote from the Microsoft announcement:

"Despite being an early implementation, the demo starts-up significantly
faster than just using asm.js as the WebAssembly binaries have a smaller file
size and parse more quickly than plain JavaScript that needs to be parsed in
the asm.js case."

[https://blogs.windows.com/msedgedev/2016/03/15/previewing-
we...](https://blogs.windows.com/msedgedev/2016/03/15/previewing-webassembly-
experiments/)

~~~
jhpriestley
You are misunderstanding. A C++ application compiled to wasm is smaller than a
C++ application compiled to a subset of javascript.

A javascript application compiled to wasm doesn't really make sense.
Javascript isn't a compiled language. The best you could do would be to store
some kind of compressed representation of the source code, along with a JIT
compiler to run that source code. It isn't a sensible thing to do.

~~~
stcredzero
_A javascript application compiled to wasm doesn 't really make sense.
Javascript isn't a compiled language._

This compiled/interpreted distinction has gotten quite fuzzy, and it has been
for decades now. Smalltalk was always a compiled language with really late
binding. It did compile to a bytecode which was interpreted at first, but that
became JIT compiled in all but one commercial VM. This all happened over a
decade ago.

Also, there is clearly a subset of Javascript programs that could be usefully
compiled down to a small, fast, compact machine language program.

~~~
geon
> there is clearly a subset of Javascript

I suppose the extra restrictions of Typescript would help. At least if you add
extra restrictions to make it easier to compile.

------
fizzbatter
Anyone know how difficult Rust -> WebAssembly will be, compared to C++ ->
WebAssembly? I'm hoping to switch some of my Go code to Rust, as i imagine Go
-> WebAssembly will be much further out _(GC and all)_, so i'm hoping Rust is
much sooner in the pipeline.

~~~
grayrest
Should just be replacing Emscripten in the toolchain with Binaryen [1].

[1]
[https://github.com/WebAssembly/binaryen](https://github.com/WebAssembly/binaryen)

~~~
brson
This is actually unlikely to be Rust's solution (at least in the long term),
because it requires running LLVM IR through emscripten to generate asm.js to
generate wasm. Making Rust and emscripten use the same LLVM IR is difficult
because emscripten has a large out-of-tree LLVM patch that Rust would need to
share.

The wasm backend though is in upstream LLVM, so rustc can use it directly,
bypassing emscripten for translation of Rust.

------
gregwtmtno
I see the comments here are overwhelmingly positive, so I will keep an open
mind. That said, someone please correct me if I'm wrong, but this runs binary
code loaded over the internet in your browser? As a free-software advocate,
this concerns me.

~~~
s3th
WebAssembly is an open source runtime developed under the governance of a W3C
Community Group [0]. The binaries that get sent over the wire are simply more
efficient ways to pack existing types of code. We will soon have a textual
encoding that makes modules easy to introspect [1] and we have a long list of
tooling plans to make sure that the web stays open and debuggable [2].

[0]:
[https://www.w3.org/community/webassembly/](https://www.w3.org/community/webassembly/)

[1]:
[https://github.com/WebAssembly/design/blob/master/TextFormat...](https://github.com/WebAssembly/design/blob/master/TextFormat.md)

[2]:
[https://github.com/WebAssembly/design/blob/master/Tooling.md](https://github.com/WebAssembly/design/blob/master/Tooling.md)

~~~
kuschku
Great!

We should make sure that browsers refuse to run any code in the future that
isn’t available in its full source.

Yes, that includes ReCaptcha

/me looks angrily at Google

~~~
dlubarov
I think the idea is that WebAssembly apps will normally be closed-source, but
browsers will ship with disassemblers, making it easy to inspect the app logic
in a common text format.

~~~
lisivka
Then every exe file is open-source, because we have disassemblers. Don't lie
to yourself: webassembly is for closed-source applications. They will be
compiled by an obscure compiler, so dissassembling back to logical code will
be too costly to be practical. We saw this many times: for v1, disassembler
works perfectly and maps 1:1 from binary to code, but for version xxx.0 it's
no longer true, because of various tricks and optimizations.

~~~
dlubarov
No one's saying wasm apps will be open source, just that there will be a
reasonable way to inspect their logic. Of course making sense of certain wasm
apps will be challenging. JS code can be hard to follow as well, if it was
generated by a tool like GWT, or minified, or obfuscated.

~~~
lisivka
I am agree, that wasm will be on par with generated/minified JS right now, but
I predict that wasm will beat JS in future versions. My prediction is based on
experience. It is very easy to introduce a binary thing which is hard to map
to flat text. I.e. first version of wasm will be 1:1 map to JS, but NEXT
versions of wasm will introduce optimizations, which are quite possible in
compact binary format but are not possible in flat text format, so 1:1 map
from wasm to JS will be broken.

------
sp332
Are there any plans to run WebAssembly outside of a browser? Would it be
difficult (once the binary format is nailed down) to distribute a standalone
program?

~~~
tracker1
Given that node.js uses v8, and there are a few options for stand-alone
distribution of node-based apps [1], I'm sure there will be many options (by
the end of the year most likely)... Though, I'm not sure why you wouldn't take
a more direct approach to building your code to different platform targets
directly if you're using a compile language already... though if you're
building web and want a standalone, I can see that.

[1]
[http://stackoverflow.com/a/12486874/43906](http://stackoverflow.com/a/12486874/43906)

~~~
sp332
But you only have to compile once for all platforms (famous last words, I
know). Including future platforms, platforms you don't know about, and
platforms you don't care about but your users do.

------
iLoch
Hmm, I wonder if and what people will switch to when they're not forced to use
Javascript. Now any language could become a server side + client side language
like JS is now.

Will I have the ability to write a library in one language and use it in
another as long as they both compile to wasm?

~~~
netghost
Finally I can write in HyperTalk!

~~~
pekk
The point being that nobody uses or has any good reason to use HyperTalk these
days. But the same is not true of many other languages. Javascript is not the
last language anyone will ever need.

------
spriggan3
So who's going to be first to recreate an entire Flash runtime for WASM? ;)

~~~
al2o3cr
Even better, port the JVM and the applet infrastructure for maximum "remember
the last time we did this exact thing" retro-lulz.

~~~
spriggan3
> Even better, port the JVM and the applet infrastructure for maximum
> "remember the last time we did this exact thing" retro-lulz.

You cant port the entire applet infrastructure since WASM is limited to the
same API as Javascript. If WASM doesn't support multithreading, languages
targetting WASM wont.

~~~
daurnimator
But it does support multithreading.

Things missing are usually specific external protocols. e.g. being able to
make a TCP socket; (or higher level things like ignoring CORS).

------
Touche
So when is Google going to deprecate Native Client?

~~~
jfbastien
When WebAssembly is further along the capabilities of PNaCl should be
polyfillable to WebAssembly, and it would then make sense to ship one fewer
VM. Otherwise NaCl and PNaCl have a solid track record of running code near
native speed in an extremely secure sandbox. It's under Chrome's Vulnerability
Reward Program, you're welcome to look for payoffs ;-)

------
dccoolgai
For all the complaining about it, I think I will actually be a little sad to
see Javascript go. It wasn't perfect, but it had a powerful unifying effect on
the Web Community when we could write, share and learn about our code in a
higher-level scripting language that we could all read. (Even if there were
some surprising little quirks that took a while to get used to.) Despite the
stated intention from WASM - there is just something fundamental about AST
trees - no matter how well you pretty-print them - that doesn't allow sharing
and shared learning the same way. As a run-of-the-mill guy who makes my bread
maintaining websites as much as greenfield-developing them, I feel like I'm in
for a bit of a rough ride trying to decipher and debug binary/AST code
compiled from Perl (or whatever). Guess I'll have to suck it up and learn to
do it, though.

~~~
jfbastien
JS isn't going anywhere. wasm and JS are a dynamic duo, complement each other.

~~~
dccoolgai
It seems like they "could" complement each other, but that's not a defining
characteristic of WASM. WASM, as I understand it, essentially allows me to
take my higher-level language like Python/Haskell/Perl/(Maybe also JS) and
compile an AST that can be interpreted by the engine on the client-side. Which
is great for Python/Haskell/Perl developers that they no longer have to pay
the toll of learning/sharing/contributing to JS - they are Haskell devs, maybe
they shouldn't have to contribute to JS. We can call that a good thing, but
let's not pretend that doesn't marginalize JS (which - again!! - maybe it
should). "But they still don't have access to the DOM" is not much of an
impediment to that Perl dev, and means as your run-of-the-mill guy I now have
to debug the Perl-produced WASM AST (Maybe pretty-printing will let me read it
in 5 hours instead of 12, but I'm still reading binary/AST which does not seem
like an awesome time) and the cruft from whatever Perl-WASM binding library
they forked from Github. Again - I know this makes life better for that Perl
dev, and maybe he/she deserves it. But unless I'm missing something, I don't
see how allowing that dev to (basically) skip JS in their path from whatever
IDE Perl devs use to the Web makes WASM "chummy" with Javascript. In fact, it
seems like now that dev will start making/contributing to libraries that
conform to their stack (Perl-specific web libraries that compile to WASM). Now
if I want to contribute to that library - which is now a part of the web - I
have to learn Perl. Before, that Perl dev would have had to learn Javascript -
which I know sucks for them - but it was good for me and good for
Javascript... and I would say "good for the web". We were all speaking the
same language, which led to an explosion of learning and collaboration. Sure,
.3 != .1 + .2 But it was that way for all of us. Now everyone is going to go
back to their own little feifdoms and just tipping their hat to JS along the
way with a lightweight DOM binding port.

------
systems
does this mean i wont have to learn javascript, css, d3, svg, typescript,
jquery, etc ... to make webistes and web apps

~~~
untog
From my understanding, WebAssembly won't have DOM access. So it certainly
won't replace jQuery, D3 or CSS any time soon.

~~~
s3th
WebAssembly doesn't intend to replace jQuery, D8, or CSS. However, we
definitely plan to enable efficient DOM access. Doing so requires supporting
some sort of native Garbage Collection, as well as the concept of opaque
reference types. See more here:
[https://github.com/WebAssembly/design/blob/master/GC.md](https://github.com/WebAssembly/design/blob/master/GC.md)

~~~
tadlan
Any specific plans for python support?

~~~
jfbastien
Python is just another language VM. C Python should work just fine in
WebAssembly, and bridging the APIs to the web (e.g. filesystem, etc) is
already possible through Emscripten.

We don't plan to do things for WebAssembly, we plan to make WebAssembly
powerful enough that anyone can run their language VM :-)

~~~
esailija
I think what they meant is that they could use python without having to also
ship the implementation like CPython. I mean, that thing is huge. How is it
feasible to serve 10mb for a website?

~~~
tanlermin
Yes, thats what I meant.

------
amelius
Will WebAssembly allow us to create custom video codecs? Or is there still a
bottleneck somewhere that makes this unrealistic?

~~~
espadrine
You could already make video codecs in JS, or in C using asm.js. It is
absolutely realistic; see for instance the jsmpeg project:
[https://github.com/phoboslab/jsmpeg](https://github.com/phoboslab/jsmpeg).

It is unlikely to ever compete battery-wise with hardware support for a codec,
however.

~~~
jfbastien
Right: direct hardware support can't be beat. Once WebAssembly has solid SIMD
support and memory management that allows zero-copy then it should be* as good
as it gets without direct hardware support.

* Assuming we're smart about security check elimination and SIMD codegen, which are both hard to do right.

~~~
chrisseaton
I don't think WebAssembly is likely to be any faster than JavaScript is it?
It's literally the same compiler in V8.

~~~
Cthulhu_
Oh but it is; see also asm.js, which is a subset of JS that removes a lot of
the potential performance bottlenecks by removing those features from JS
(mostly having to do with JS' dynamic nature, iirc).

Or in other words: javascript is an interpreted script language, webassembly
is a compiled binary format.

~~~
chrisseaton
> Or in other words: javascript is an interpreted script language, webassembly
> is a compiled binary format.

They're both just-in-time compiled. It doesn't matter if your program comes in
as source code or a binary format if you're compiling it dynamically.

But I didn't know that WebAssembly ran under asm.js semantics. I guess that's
the difference.

~~~
jfbastien
WebAssembly has its own semantics, similar to asm.js (statically typed) but
much cleaner because it doesn't need to map onto JavaScript.

------
megaman821
Would there be any benefit to compiling dynamic languages with GCs (like
Python or Ruby) to WASM? It is cool that is technically possible, but this
looks like a target for C, C++, and Rust code.

~~~
jfbastien
C Python and Ruby should "just work" because you can compile their GC into you
wasm module.

More general-purpose GC will be supported, but not in the initial release:
[https://github.com/WebAssembly/design/blob/master/GC.md](https://github.com/WebAssembly/design/blob/master/GC.md)

------
legutierr
Does anyone who is familiar with WebAssembly development know what kinds of
things Dynamic Linking (mentioned among the future features) will enable? For
instance, would it permit the creation of optimized WebAssembly libraries
written in C++ that could be called by a JavasSript program (say, for things
like image processing)? Would it eventually permit library sharing between,
say, a Python runtime compiled to WebAsembly and JavaScript in the browser?

Because that would pretty cool.

~~~
titzer
You can already do some of that without the dynamic linking feature. There is
a JS API to instantiate a WebAssembly module, providing JS functions that are
callable as external functions from within the WASM module. Conversely the
WASM module exports functions that are callable directly from JS.

This allows rudimentary interop between JS and WASM, and dynamic linking will
make it possible to deliver your WASM application in separate pieces, e.g. a
large, rarely-changing library that is cached, precompiled, by the browser,
and a small, often-changing application piece.

------
moron4hire
This is going to be huge for the WebVR community. The demo actually ran great
on my janky laptop, whereas the ASM.js version at a lower resolution ran at
the considerably crappy level I had come to expect of Unity HTML5-built apps
on an Intel integrated GPU. Faster = more efficient, also, so equivalent demos
should burn less battery power on my smartphone as well, which means less heat
build up, which means a longer time before the GPU throttles down.

------
formula1
More importantly, will rust compile to wasm one day?

~~~
rbalicki
[https://users.rust-lang.org/t/rust-to-js-with-
emscripten/587](https://users.rust-lang.org/t/rust-to-js-with-emscripten/587)
There's been interest in compiling to JS for a while. I don't follow Rust
closely, so I'm not sure how much progress there has been.

~~~
steveklabnik
Lots! We're getting really close, actually.

------
iagooar
When I read news like this, I think: this is the cool stuff you should be
doing, not maintaining a lousy e-commerce shop...

~~~
cududa
I work on OS level stuff myself, but I find this comment insulting. What are
you even working on?

------
crudbug
Giant Leap for Web Platform.

How is the mapping from wasm to asm done, at all?

Are they directly mapping from web world to native world in a sandbox ?

~~~
sbierwagen
[https://github.com/WebAssembly/design/blob/master/FAQ.md](https://github.com/WebAssembly/design/blob/master/FAQ.md)

~~~
crudbug
{Any Language} => WASM => {OPTIMIZATION/COMPILATION} => NATIVE CODE

------
batmansmk
It is a wonderful news. Firefox version is ready too.

------
tracker1
I can't help but to think that this could be a huge win for binary modules in
node.js, as it could finally allow for cross-platform, prebuilt binary modules
without the tight coupling and build dependencies that are currently needed.

------
Illniyar
This is moving fast.

Does anyone know if theres a webassembly to js compiler to support legacy
browsers?

~~~
s3th
The Emscripten toolchain can be used to produce both WebAssembly and asm.js
from the same codebase [0]. There are also the nascent beginnings of a
translation tool from WebAssembly to asm.js here [1] (look for wasm2asm).
Ultimately, it should be possible to write a streaming polyfill for
WebAssembly, but no one has gotten around to making anything suitable for
production yet. You're better off producing a separate fallback asm.js bundle
for now.

[0]:
[https://github.com/kripken/emscripten/wiki/WebAssembly](https://github.com/kripken/emscripten/wiki/WebAssembly)

[1]:
[https://github.com/webassembly/binaryen](https://github.com/webassembly/binaryen)

------
tadlan
Question please: Even though there is stated desire to support python etc vm,
this will be hampered by the need for the client to download the large VM vs
native code that can be distributed itself, correct?

~~~
jfbastien
Correct, though we're working on dynamic linking to ease the pain, and
improving compilers such as LLVM so that the generated code is smaller.

~~~
tadlan
Thanks. I'm not familiar with dynamic linking. What will that do?

~~~
binji
There's a response above this one from titzer describing it, or you can read
more here:
[https://github.com/WebAssembly/design/blob/master/DynamicLin...](https://github.com/WebAssembly/design/blob/master/DynamicLinking.md)

------
hutzlibu
This is great news! And a nice working demo ... And a general question about
wasm - since typescript can be strictly typed, would it benefit much, if it
would be compiled to wasm?

~~~
constexpr
I currently write compilers that target JavaScript and have looked a
TypeScript a lot for something like this. In practice, TypeScript isn't
actually strictly typed. There is a ton of TypeScript code out there that does
stuff like run-time prototype manipulation (mixins, for example), using
arbitrary objects as hash tables, and liberal use of the "any" type.

So either you cross-compile a JavaScript VM to be able to handle everything
(super slow and bloated, especially without the ability to JIT compile
executable code) or you pick a small subset of TypeScript to compile, in which
case it wouldn't really be TypeScript at all.

Plus TypeScript doesn't have integer types (only doubles) so it would generate
pretty inefficient code. JavaScript JITs do a _lot_ of work to turn usage of
doubles into integers based on run-time behavior that is unknowable at
compile-time.

~~~
hutzlibu
I think I would be happy with the subset and the add of Integers ... Dynamic
languages are great for rapid prototyping and debugging, but once the
programming is done and everything is clear, I don't realy need stuff like
window["foo" \+ someString](1,2,3) or the "any" type anymore ... I don't think
it will be too hard, to "strongtype" your ts or js if there will be such a
subset and you have a smart IDE.

------
BinaryIdiot
Oh man I'm very excited about this! Great job all around!

Web Assembly should make code more portable and faster on the web. No more
transpiling to JavaScript (which honestly is a hack; going from one language
to another language which is then compiled). If you want to use CoffeeScript,
even though I dislike it, you'll be able to compile directly to WebAssembly
instead.

I can't wait until this is fully baked with DOM access, etc.

~~~
jfbastien
Transpiling some dynamic languages to JS is still sensible. WebAssembly is
initially for static languages, and eventually (with JIT and GC support) it'll
be usable as a building block to host dynamic language VMs.

~~~
BinaryIdiot
> Transpiling some dynamic languages to JS is still sensible.

It's still practical, today, should you want to use something other than JS
but I don't think it's that sensible. You take one language's syntax and
idiosyncrasies, convert it to another language with its own, sometimes
differing, idiosyncrasies and now you have to debug it, sometimes in a
different language than it was written it.

I don't mind TypeScript or any of the others but I think WebAssembly is what
makes those language great; transpiling to JavaScript is a hack.

Just imagine ECMAScript 7 then ECMAScript 8 support coming in very quickly
after announcement because your JavaScript now compiles to WebAssembly. You
won't have to wait or deal with browsers that are lacking the necessary APIs;
it'll "just work" because it's all compiled to WebAssembly.

~~~
ZenoArrow
That's not what jfbastien is saying. The point is, until the time when
WebAssembly has a GC and a JIT, many dynamic languages simply won't be able to
target WebAssembly (unless the dynamic language developers create their own
bespoke JIT/GC), so you may as well stick to targeting JS.

At the point at which WebAssembly gets a JIT and GC, then the situation
changes.

~~~
BinaryIdiot
Yup I know; I never said anything to the contrary just talking up
WebAssembly's advantages. This release is a very early and somewhat rough
version.

------
xhrpost
I know programmers sometimes write directly in assembly for certain
performance enhancements and certain hardware access. Is there a foreseeable
reason someone would program directly in WebAssembly though? I realize that's
not the reason this technology exists, just curious.

~~~
abecedarius
When asm.js came out I ported [http://wry.me/hacking/Turing-
Drawings](http://wry.me/hacking/Turing-Drawings) to use it. It would've made
as much performance sense to do the same for WebAssembly. This is not quite
the same as hand-coding WebAssembly -- it's making a custom code generator for
a little language.

------
ilaksh
Nim, which is objectively the best programming language, is perfect for Web
Assembly.

------
z3t4
It might sound like a stupid question, but is it faster then vanilla
JavaScript!?

~~~
spriggan3
Yes since it's lower level, and No since you'll still be limited to Web APIs
like Javascript. The code isn't being executed outside the browser like a Java
applet or Flash.

------
spriggan3
Great news, this is the beginning of the "Javascript Less" movement.

~~~
ludamad
It'll be really interesting if people think of JavaScript more as a highly
available scripting language, rather than a necessity.

------
noiv
That three major browser teams implement and publish a new standard/technology
at the same time is exciting. OTOH I can't believe we start over again with
Assembler (a machine language).

~~~
dlubarov
Well it's not really machine code, since no hardware uses wasm as its native
instruction set; it's just low level bytecode.

And it's really intended as a compilation target; I don't think anyone wants
or expects average web developers to code in wasm.

~~~
noiv
Well, it runs on a virtual machine, not that much different. And the design
doc states "writing by hand", but the s-expressions look interesting. Finally
Lisp for browsers :)

------
bobajeff
I wonder if Google has any plans on using C++ in any of their web applications
now.

Might help them improve Google Docs a lot if they could utilize some mature
C++ libraries from a desktop word processor.

~~~
nly
Google can already run whatever code they want on your docs server side.

------
shurcooL
This is really exciting, because it's going on a great path and it's a matter
of time before all this is available out of the box!

Is anyone working on a Go to WebAssembly compiler yet?

~~~
ZenoArrow
> "Is anyone working on a Go to WebAssembly compiler yet?"

I don't think that'll work until WebAssembly has GC, which isn't likely to be
ready for a while.

~~~
nulltype
Go has it's own GC, so why would it need WebAssembly's? Does web assembly
disallow programs from doing their own GC?

~~~
ZenoArrow
Go has a GC that runs on top of an OS. The virtual machines that run
WebAssembly are highly likely to have different mechanisms to manage memory
compared to an OS that Go runs on, so Go's GC will not work 'out of the box'.

This leaves two options:

1\. Go developers could write a GC especially designed to enable Go on
WebAssembly.

2\. Go developers could wait until WebAssembly gets its own GC implementation,
and make use of that.

Considering option 2 is less work, and that a GC for WebAssembly is on the
WebAssembly roadmap (check the GitHib page for details), I'd suggest option 2
is what will end up happening.

------
kin
Is there any news for WebAssembly on mobile browsers?

~~~
jfbastien
It should "just work", but we're still at the experimental stage right now so
it may break randomly. It's not production quality yet, but mobile is a first-
class platform for launch.

------
neals
Is this in a state where I can go and try making experiments in webassembly?

~~~
azakai
It's a little early, so things are not easy to use yet. Spec still changes,
tools still change and break, nothing is optimized for convenience yet, etc.
But here is how to use emscripten to emit WebAssembly currently,

[https://github.com/kripken/emscripten/wiki/WebAssembly](https://github.com/kripken/emscripten/wiki/WebAssembly)

------
randyrand
Anyone gonna write an LLVM backend for this? =D _mouth waters_

~~~
sunfish
Already on it :-).

[https://github.com/llvm-
mirror/llvm/tree/master/lib/Target/W...](https://github.com/llvm-
mirror/llvm/tree/master/lib/Target/WebAssembly)

(linked to the Github mirror because the LLVM viewvc is currently down)

------
anthk
The day WebAssembly is pushed into mainstream I'd use a web browser with no
support for it at all.

~~~
83457
Lynx?

~~~
swiley
I always use elinks when I'm trying to get work done as anything worth reading
(documentation etc) works just fine in it but you don't have all the
distracting "web stuff".

