
From Asm.js to WebAssembly - fabrice_d
https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
======
sixdimensional
I think this quote speaks volumes - "WebAssembly has so far been a joint
effort among Google, Microsoft, Mozilla, and a few other folks." Sometimes I
think maybe, just maybe the W3C and other web standards groups finally have
some wind behind their sails.

It may have taken a while, but with all these individuals and organizations
cooperating in an open space, we may finally advance yet again into another
new era of innovation for the web.

I am really excited about this, much like others in these comments.

We have been beating around the bush to have a true assembly/development layer
in the browser for a long time: Java applets, Flash, Silverlight, you name it
- but no true standard that was open like Javascript is open. This component
has the possibility of being the neutral ground that everyone can build on top
of.

To the creators (Brendan Eich et. al) & supporters, well done and best of luck
in this endeavor. It's already started on the right foot (asm.js was what lead
the way to this I think) - let's hope they can keep it cooperative and open as
much as possible for the benefit of everyone!

~~~
walterbell
_> WebAssembly has so far been a joint effort among Google, Microsoft,
Mozilla, and a few other folks_

Is Apple participating?

~~~
bryanlarsen
Yes: "I’m happy to report that we at Mozilla have started working with
Chromium, Edge and WebKit engineers "

[https://blog.mozilla.org/luke/2015/06/17/webassembly/](https://blog.mozilla.org/luke/2015/06/17/webassembly/)

~~~
michaelmior
This doesn't seem to necessarily imply that Apple is directly involved. But
it's good to know that Safari should be included in this effort.

~~~
bd
That WebKit issue about WebAssembly was filed by engineer working on
"compilers and language runtime systems at Apple":

[http://www.filpizlo.com/](http://www.filpizlo.com/)

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

~~~
kevinwang
Although that doesn't necessarily mean that Apple the company is involved, no?

~~~
walterbell
Maybe the engineer who is involved wasn't able to obtain organizational
signoff in time for Apple to put their name on the list of top-level endorsers
of the proposed standard? Hopefully Apple can issue a statement later.

~~~
SiVal
_WebAssembly has so far been a joint effort among Google, Microsoft, Mozilla,
and a few other folks. I’m sorry the work was done via a private github
account at first, but that was a temporary measure to help the several big
companies reach consensus and buy into the long-term cooperative game that
must be played to pull this off._

So, the effort to get buy-in from the big companies that matter has been going
on for some time, and now that we've done that, here's the result: Every big
company that matters except Apple.

It's not as though the list of the four big companies that matter is too long
to reasonably be expected to name the fourth, and the name of the fourth is
not webkit.org or Fil Pizlo.

So, it seems to be either an "Oops, we accidentally left one of the four out
of this important announcement," or there is still enough of a problem with
Apple that we decided not to delay the announcement any longer to wait for
them.

~~~
BrendanEich
You are assuming a false dichotomy. There's a third possibility: what with a
big four-letter-acronym developer conference and lots of other spinning
plates, the full buy-in to include the company name didn't make the deadline
set to get everyone else on board.

Since Fil opened a webkit bug to implement wasm, I would at least hedge my
false-dichotomy bet and avoid getting my mad on. Free advice, take it or leave
it.

(The first paragraph is actually me telling you pretty much what happened.
Same thing as with WHATWG launch in 2004, BTW. Does not mean "OMG there is
something WRONG and only TRULY SHINY COMPANY noticed and OBJECTED". Yeesh.)

~~~
SiVal
As long as Apple hasn't officially agreed to this, and you seem to have some
sort of embargo on even referring to them by name, something other than full
buy-in from them is still a possibility. This possibility makes me nervous,
because I think wasm is just what the Web needs, and I don't necessarily trust
Apple to have "whatever is best for the open Web" as a guiding principle.

As for "getting my mad on," you seem to have gone off on some sort of tirade
at the end there implying--how ironic--that I actually wanted TRULY SHINY
COMPANY to save us from wasm, and your caps-lock key seems to have gotten
stuck when you banged on it.

~~~
BrendanEich
Please accept my apologies for the ALLCAPs. You were nervous in a way that
suggested to me the kind of fannish knee-jerking that I unfairly lampooned.

I hope you can relax. All will be clear pretty soon, I am certain. There's no
need to be nervous. Well, no need to be more nervous than usual! ;-)

~~~
SiVal
All is well between us, and I can't thank you enough for what you're trying to
do. Here I thought ES6 was the best news of the year for Web dev, but wasm
will beat it _by far_ \--as long as the long-term cooperation you (correctly)
said it needs really comes through. It's hard to relax when we're soooo close
to something this tantalizing, all but one have officially committed, but it
has to be unanimous, and that one is not...yet...saying....

I'll watch these pages and let out a woot! the minute Apple officially makes
it unanimous.

------
AriaMinaei
Does everyone think this is good news?

I'm all for making the web faster/safer/better and all that. But I am worried
about losing the web's "open by design" nature.

Much of what I've learned and am learning comes from me going to websites,
opening the inspector and stepping through their code. It's educational. You
learn things you may never read about in tutorials or books. And it's great
because the author may have never intended for their code to be studied. But
whether they like it or not, other people will learn from their code, and
perhaps come up with [occasionally] better versions of it on their own.

This has helped the web development to evolve faster, and it's obvious how
democratizing this "open-by-design" property is, and I think we should be
concerned that it's being traded away for another (also essential) property.

Human beings cannot read asm.js code. And a bytecode format will be more or
less the same. So, no matter how much faster and more flexible this
format/standard is, it will still turn web apps into black boxes that no one
can look into and learn from.

~~~
aquilaFiera
WebAssembly isn't going to kill that notion; uglify already did. Nearly all
codebases on big sites get run through a build process these days. The open
web continues to live on through the open and free software movements.

~~~
AriaMinaei
I agree that the web is far from the full ideal of "open-by-design", but it's
still the most significant platform providing it to some extent.

The problem of uglify can be mitigated if someone invented a binary format for
JS that was interchangeable with the current text format. The format would
reduce the code's size, while keeping it readable (you'd just have to run it
through a binary-to-text decompressor).

I should also say that you _can_ read uglified/obfuscated code. It just takes
more patience. Example: if PS was written in JS and then obfuscated, how hard
do you think it would be to find out how their color transformation algorithms
are implemented?

You can't say the same thing for asm.js code though.

~~~
derefr
What's the difference between deobfuscating code, and decompiling it? Either
way you end up with a weirdly-structured, canonicalized, symbolless mess.

~~~
AriaMinaei
The binary format that I mentioned/proposed would map one-to-one with a text
format. They would be interchangeable. That means if you open a file in that
binary format in a text editor (with the right plugin), you'd see almost
exactly the original code. It's not decompilation. Only decompression.

~~~
derefr
I think you're confusing _cost of parsing_ with _cost of lexing_. A 1:1 binary
representation of JS (like HPACK is for HTTP headers) wouldn't decrease
_parsing_ time (the time it takes to turn a stream of recognized tokens into
an AST) at all, which was the goal here.

~~~
AriaMinaei
Agreed, but the idea is still beneficial. If 1:1 binary representation for the
data from the lexer doesn't yield much benefit, then a representation for the
AST might.

And reading from that data could be much faster. And with a supposedly smaller
file format, it probably wouldn't be so necessary for a minifier to rename
symbols to single-letter ones to save a few more bytes.

[Edit: added the following paragraph]

This could yield a smaller file format (which is what people usually want from
JS minifiers), without sacrificing the readability of the JS code.

~~~
icebraining
Renaming symbols, and minification in general, is not really "necessary", it's
just something people do to extract a few % more of performance. If they had
that file format, they'd still have exactly the same reasons to rename
symbols, so they'd still do it.

After all, if people cared about leaving their files readable, they'd just
publish the non-minified version as well. Those who don't, won't avoid
renaming either.

~~~
AriaMinaei
I agree that renaming symbols would still save a few more bytes, but I still
think that with the right file format, symbol renaming and mangling would
become an insignificant, unnecessary micro-optimization.

But that should only be tested in practice, so ... :)

~~~
dllthomas
This seems backwards. If I have JS source and the identifiers take up 10% of
it, then symbol renaming and mangling can shrink my code size by something
less than 10%.

If we shrink that other 90%, so that the formerly 10% is now 80%, renaming
becomes _more_ attractive.

This doesn't hold if people have a fixed problem with a fixed solution and
fixed constraints... but problems and solutions grow.

~~~
AriaMinaei
> _If we shrink that other 90%, so that the formerly 10% is now 80%, renaming
> becomes more attractive._

Convinced :)

------
pcwalton
Having been on one side of the perpetual (and tiresome) PNaCl-versus-asm.js
debate, I'm thrilled to see a resolution. I really think this is a strategy
that combines the best of both worlds. The crucial aspect is that this is
polyfillable via JIT compilation to asm.js, so it's still just JavaScript, but
it has plenty of room for extensibility to support threads, SIMD, and so
forth.

~~~
JoshTriplett
> The crucial aspect is that this is polyfillable via JIT compilation to
> asm.js

So is PNaCl, with pepper.js. The difference there is that PNaCl also provided
a more full-featured API, which nonetheless was harder for other browsers to
support. Personally, I would have been happy to see NaCl-minus-Pepper
standardized, since the sandbox would have been much easier to support than
the APIs; browsers could then choose what superset of APIs to expose to that
sandbox.

~~~
pcwalton
By "a more full-featured API" do you mean that Pepper has more features than
the Web APIs? If so, then it's not polyfillable (and the solution is to add
more features to the Web APIs). Or if you mean that PNaCl has more features
than asm.js, then the solution is to add those features to JavaScript.

I'm glad that asm.js is the starting baseline for this work, because its exact
semantics are standardized via ECMA-262. All that has to be done to define its
behavior precisely is to create a new syntax for it. LLVM bitcode, by
contrast, has a lot of undefined behavior. You could try to spec a subset of
it, but why go to that trouble when TC-39 has already done the work for you?

~~~
stcredzero
_it 's not polyfillable_

I'd be interested to know where/when this "polyfillable" term came about. It's
not readily Google-able yet.

~~~
csense
If you dig through my comment history, you might be able to find a comment I
wrote on my first exposure to this term maybe ~2 years ago. I was utterly
befuddled because I thought it was a graphics rendering algorithm (setting
pixels in a framebuffer corresponding to the interior of a polygon specified
as an edge list), and was horribly confused about why an article discussing
some web technology would suddenly transition into a geometric problem utterly
disconnected from the original topic.

~~~
Retra
It's a pretty awful term...

~~~
SquareWheel
It sure beats "shiv" though. Glad that one has started fading.

~~~
pokpokpok
shim makes much more sense than shiv

------
wora
Oberon language had a similar system called Juice back in 1997. It does
exactly the same thing, e.g. using binary format to store a compressed
abstract syntax tree as intermediate format which can be compiled efficiently
and quickly. I think it even has a browser plugin much as Java applet. Life
has interesting cycles. I don't have the best link to the Juice.

[1]
[https://github.com/berkus/Juice/blob/master/intro.htm](https://github.com/berkus/Juice/blob/master/intro.htm)
[2] ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf

~~~
gecko
Honestly, everything we're doing recently feels like rediscovering Oberon.

Oberon had name-based public/private methods, like Go. It had ahead-of-time
compilation of bytecode, as you pointed out. It had CSP-style concurrency,
again like Go. The web for the last two years feels like we're rediscovering
Smalltalk and Oberon and acting like we've just invented everything anew.

~~~
BrendanEich
We didn't acknowledge a debt to Oberon (did Java? It owes one too, Bill Joy
evaluated Oberon closely).

My pal Michael Franz at UCI studied under Wirth. Michael and a PhD student,
Chris Storck, did an AST encoder years back that influenced me and that I
referenced re: wasm.

Oberon's great. JS was in the right place and right time. What can I say? I've
been taking all the best ideas from the best projects and trying to get them
incorporated, ever since 1995.

~~~
gecko
Sorry, just to be clear, I don't see anything wrong at all with raiding the
best ideas from older languages. It's actually awesome: it means those ideas
get used. I'm genuinely just amused at the cycle.

------
dankohn1
This is enormous news. I could see a scenario where, in ~5 years, WebAssembly
could provide an alternative to having to develop apps with HTML for the web,
Swift for iOS, and Java for Android. Instead, you could build browser-based
apps that actually delivered native performance, even for CPU- and GPU-
intensive tasks.

Of course, there would still be UI differences required between the 3
platforms, but you would no longer need 3 separate development teams.

~~~
muglug
This was also what Java applets were meant to deliver – I remember running
some pretty great Java Applet-based games back in the day.

But Java ran as an embed, not a browser-level feature, and was much slower to
load than Flash (which came to offer much of the same functionality in an
easy-to-use IDE).

~~~
the8472
I can already imagine a minimal java VM (just transforming bytecode to wasm
instead of JITing to machine code) inside browsers, thus allowing java (or any
of the other JVM languages) running in the backend and frontend.

~~~
smrtinsert
Google previewed some Android to chrome app compiler a while ago - can't
remember the details. I imagine it would be a pretty good starting point for
such a project instead of a full vm.

~~~
binji
ARC
([https://developer.chrome.com/apps/getstarted_arc](https://developer.chrome.com/apps/getstarted_arc))

------
amyjess
This is probably the best thing that can happen to web development.

For quite a while, I've been thinking about how instead of hacks like asm.js,
we should be pushing an actual "Web IR" which would actually be designed from
the ground up as an IR language. Something similar to PNaCl (a subset of LLVM
IR), except divorced from the Chrome sandbox, really.

~~~
MichaelGG
I think that's what lots of people have thought since the 90s with Java
applets. Despite ES6 and "it's not _that_ bad", there's a lot of people that
would really like to not have to deal with JS.

Edit: Really, it's annoying this didn't happen sooner. If Microsoft would have
thought of this early on and pushed it, they could have gained a lead in
compilers and developer tools, for instance.

------
kodablah
I think the biggest win is
[https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#gcdom-
integration). Now instead of asm.js being only for emscripten-compiled code
(or other non-GC code) WebAssembly can be used for higher level, GC'd
languages. And even better,
[https://github.com/WebAssembly/design/blob/master/NonWeb.md](https://github.com/WebAssembly/design/blob/master/NonWeb.md),
means we may get a new, generic, standalone VM out of this which is always
good (I hope I'm not reading in to the details too much). As someone who likes
to write compilers/transpilers, I look forward to targetting this.

~~~
JoshTriplett
I'm _really_ hoping that WebAssembly doesn't bake-in higher-level features
like garbage collection. That would preclude replacing GC with something
better, such as Rust-style memory management.

Hopefully this will take more inspiration from actual assembly language and
virtual machines, rather than from bytecode languages.

~~~
azakai
GC support doesn't prevent having Rust-style compile-time memory management.
In fact, Rust itself may add a GC at some point.

~~~
JoshTriplett
As a library, though, which is very different than providing it as an inherent
part of a language runtime.

I'm hoping WebAssembly doesn't inherently imply a runtime.

~~~
azakai
Efficient GC requires tight integration with LLVM, and I assume that means
also tight integration with the Rust compiler. I don't think that can be done
as a library or even a plugin.

~~~
iopq
Rust doesn't need an efficient GC like the kind Java has. Most of the
resources you need in Rust are freed when they get out of scope.

What Rust needs is just a better RC implementation. This is because only a
small part of your data is reference counted, so it fits better with how Rust
works, so an efficient implementation allows it to combine with ownership
semantics to outperform even very advanced generational GCs.

------
addisonj
Prepare for the onslaught of new (and old) languages targeting the web.

While this is welcome news, I am also torn. The possibilities are pretty
amazing. Think seamless isomorphic apps in any language that can target
WebAssembly and has a virtual dom implementation.

However, it finally seems like JS is getting some of its core problems solved
and is getting usable. I wonder if it might have short term productivity loss
as the churn ramps up to new levels with a million different choices of
language/platform.

Either way, it will be an interesting time... and a time to keep up or risk
being left behind.

~~~
JoshTriplett
> However, it finally seems like JS is getting some of its core problems
> solved and is getting usable. I wonder if it might have short term
> productivity loss as the churn ramps up to new levels with a million
> different choices of language/platform.

This announcement means JavaScript can no longer rely on "you must target
JavaScript to work on the web" as a motivating factor. The set of people who
like JavaScript as a language in its own right can keep using it, and will
have the advantage of new JavaScript engines and extensions implemented on top
of WebAssembly. However, the set of people who would rather write in another
language will no longer be constrained by waiting for JavaScript to catch up.

Personally, I think this will be a good thing for both JavaScript and other
languages.

~~~
smrtinsert
I'm 100% ready to jump ship there. I would rather work at a shop that does any
other language besides Javascript for web guis even with more than a decade of
js dev under my belt. The problem is they are impossible to find.

~~~
virtualwhys
> The problem is they are impossible to find.

Scala.js[0], GHCJS[1], and Js_of_ocaml[2] among others.

[0] [http://www.scala-js.org/](http://www.scala-js.org/)

[1] [https://github.com/ghcjs/ghcjs](https://github.com/ghcjs/ghcjs)

[2] [http://ocsigen.org/js_of_ocaml/](http://ocsigen.org/js_of_ocaml/)

~~~
benjaminjackman
I believe smrtinsert is referring to places that you could work at to write
those languages, not that the languages themselves are impossible to find. I
don't know if anyone is actually being paid by someone else to write ScalaJS,
GHCHS and/or Js_of_ocaml.

~~~
virtualwhys
> places that you could work at to write those languages

Ah, missed that, assumed OP meant if only there was a way to write JS without
having to write JS.

------
aikah
So it's basically bytecode for the web without compiling to javascript right ?

Any language can now target that specific bytecode without the need for
javascript transpilation.

For instance Flash can target this format in place of the Flash player, making
swf files future proof since backed by standard web techs.

So it's basically the return of Flash,Java applets and co on the web. And web
developers won't have to use Javascript anymore.

The only constraint is obviously the fact that the bytecode has only access to
web apis and cant talk directly to the OS like with classic browser plugin
architectures.

------
spullara
It is really too bad that at some point in the last 18 years of Java VMs being
in browsers that they didn't formalize the connection between the DOM and Java
so that you could write code that interacted directly with the DOM and
vice/versa in a mature VM that was already included. Would have been way
better than applets, way faster than Javascript and relatively easy to
implement. The browsers actually have (had?) APIs for this but they were never
really stabilized.

~~~
hello_there
I find it interesting that Java didn't become the standard for this as it
seems like it has everything and is both fast and mature.

What might be the reason?

~~~
titzer
There are several important lessons to learn from the Java bytecode format and
members of the WebAssembly (including myself) do have experience here. In
particular, JVM class files would be a poor fit for WebAssembly because:

1\. They impose Java's class and primitive type model. 2\. They allow
irreducible control flow. 3\. They aren't very compact. Lots of redundancy in
constant pools across classes and still a lot of possibility for compression.
4\. Verification of JVM class files is an expensive operation requiring
control and dataflow analysis (see stackmaps added in the Java 7 class file
format for rationale). 5\. No notion of low-level memory access. WebAssembly
specifically addresses this, exposing the notion of a native heap that can be
bit-banged directly by applications.

------
M8
If I could just use my favourite language and not feel like a second class
citizen, then I am not sure there would be anything else to complain about as
a developer, really. A mark-up bytecode so that we could forget about the
nightmare of HTML and CSS as well?

~~~
JoshTriplett
Fast-forward a few years, and imagine if a browser engine were nothing more
than a WebAssembly engine and a "default" HTML/CSS implementation. You could
replace that engine with anything you like written in WebAssembly, doing all
its own rendering and input using the lower-level APIs provided by
WebAssembly. So, every browser gets the latest rendering and elements, or at
the very least polyfills via WebAssembly rather than JavaScript.

~~~
0x0
Sounds terrible for SEO, screen readers and adblockers.

~~~
JoshTriplett
You can already build awful, non-semantic HTML today, with a giant pile of
<div> tags, CSS, and JavaScript. The web hasn't fallen apart.

Similarly, just because it'll be possible to implement a full web engine
efficiently in WebAssembly doesn't mean sites will suddenly stop paying any
attention to standards or accessibility.

As for adblockers, I can think of several ways to block ads in such a world,
including hooking the sockets API to block or sandbox access to ad-serving
hosts, or providing hot-patches that stub out common ad-serving libraries.
It'll get harder, but not impossible.

~~~
mkozlows
"The web hasn't fallen apart" for sighted users. Those non-semantic, unusable-
to-screen-reader sites are in fact an accessibility disaster for blind users,
who can find it nearly impossible to use some sites.

(And a disaster for the companies that build them and get sued later.)

~~~
JoshTriplett
> "The web hasn't fallen apart" for sighted users. Those non-semantic,
> unusable-to-screen-reader sites are in fact an accessibility disaster for
> blind users, who can find it nearly impossible to use some sites.

I'm saying that div-itis is possible today, but it's a bad idea, and as far as
I can tell many new sites still use semantic markup when available.

Along the same lines, I would expect that even if people implement a web
engine in wasm, many will still use semantic markup.

That said, I agree that people don't pay enough attention to accessibility,
and should. But I don't think wasm or wasm-based rendering engines will make
that _worse_.

~~~
0x0
Even if you use only divs, the actual text is there in UTF-8 to parse out of
the DOM, today.

If you go all-in on wasm to do "your own rendering", external software won't
know where to find a "DOM" or how to understand it, unless some other kind of
reinvented HTML-for-a-wasm-rendering-engine-defacto-standard is invented?

(This is more a rant against "let's reinvent html/css in canvas" rather
against a VM-based javascript replacement in general. Even though the latter
sounds a bit terrible as well for the open web; imagine what the web would
have looked like if .js never existed, and a flash/java .swf/.jar engine was
the only way to do scripting in a webpage.)

------
comex
Has any consideration been given to using a subset or derivation of LLVM
bitcode a la PNaCl? I know there are significant potential downsides (e.g.
according to [1], it's not actually very space efficient despite/because of
being bit-oriented and having fancy abbreviation features), but it already has
a canonical text encoding, it has been 'battle-tested' and has semantics by
definition well suited for compilers, and using it as a base would generally
avoid reinventing the wheel.

[1]
[https://aaltodoc.aalto.fi/handle/123456789/13468](https://aaltodoc.aalto.fi/handle/123456789/13468)

~~~
azakai
Of course, several of the people working on WebAssembly are actually from the
PNaCl team. And others, like the Emscripten people, have lots of LLVM
experience as well. WebAssembly is being designed while taking into account
previous approaches in this field, including of course using LLVM bitcode for
it.

LLVM bitcode is simply not a good fit for this:

* It is not portable.

* It is not designed to be compact.

* It is not designed to be quick to decode and start up

* It has undefined behavior

* It is not sandboxed.

* It is a moving target (see recent big changes to LLVM IR on geps and loads/stores)

Each of those can be tackled with a lot of effort. But overall, better results
are possible using other approaches.

------
rhaps0dy
Finally. IMO this is what the web has been calling for since AJAX went
mainstream.

They are doing great work. The client's operating system matters little now,
but it will not matter at all soon.

------
daurnimator
This still doesn't fix the biggest issue with running non-javascript code in
the browser: browsers _still_ offer _no_ way to know when a value is
collected.

e.g. if I allocate a callback function, and hand it to setTimeout, I have no
way to know when to collect it.

Sure, you can encode rules about some of the common functions; but as soon as
you get to e.g. attaching an 'onreadystatechange' to an XHR: you can't follow
all the different code paths.

Every time a proposal comes up to fix this:

    
    
      - GC callbacks
      - Weak valued maps
      - Proxy with collection trap
    

The proposal gets squashed.

Unless this is attended to Javascript remains the required language on the
web.

~~~
BrendanEich
Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to notify
in next event loop turn.

Note turn-based notification. No way will exact GC schedule be leaked via
callbacks from the GC. Ditto anything like Java's post-mortem finalization.

But your "e.g." is unclear, though. Why do you need to manually deallocate a
callback function passed to setTimeout?

~~~
daurnimator
> Read up, you've missed a memo :-P. Plan for Harmony-era weak refs is to
> notify in next event loop turn.

Got a link to the memo? I haven't heard about this one.

> Why do you need to manually deallocate a callback function passed to
> setTimeout?

One of my use cases is running lua in the browser. see lua.vm.js:
[https://kripken.github.io/lua.vm.js/repl.html](https://kripken.github.io/lua.vm.js/repl.html)

When you pass a lua function to a javascript function, I create a 'proxy'
object that holds a reference to the function in the lua VM. Only if
javascript tells me it's "done" with it can I drop the ref inside the lua VM.

~~~
BrendanEich
See, e.g.,

[https://esdiscuss.org/topic/weak-event-
listener#content-2](https://esdiscuss.org/topic/weak-event-listener#content-2)

It's hard to find something fresh. I will stir the pot at the July TC39
meeting and get the committee on the record for weak refs with turn-delayed
notification, or bust!

~~~
daurnimator
> See, e.g.,

> [https://esdiscuss.org/topic/weak-event-
> listener#content-2](https://esdiscuss.org/topic/weak-event-
> listener#content-2)

> It's hard to find something fresh. I will stir the pot at the July TC39
> meeting and get the committee on the record for weak refs with turn-delayed
> notification, or bust!

As recently as September last year you told me it may happen... but with an
indeterminate timeframe: [https://mail.mozilla.org/pipermail/es-
discuss/2014-September...](https://mail.mozilla.org/pipermail/es-
discuss/2014-September/039078.html)

~~~
BrendanEich
Yeah, it needs an active champion. I'll poke likely champs.

------
JoshTriplett
I'm interested to see what the API side of WebAssembly looks like in browsers;
hopefully this will make it easier to expose more full-featured sandboxed APIs
to languages targeting the web, without having to tailor those APIs to
JavaScript. For instance, API calls that actually accept integers and data
structures rather than floating-point and objects.

For that matter, though in the short-term this will be polyfilled via
JavaScript in browsers, it'll be fun to see the first JavaScript-to-
WebAssembly compiler that allows you to use the latest ECMAScript features in
every browser.

~~~
azakai
The API story for wasm on the web is the set of existing web APIs. That
provides the same security model and capabilities as the web has right now.

Currently wasm can't access web APIs except by calling out to JS, which would
then call the API, but in the future, direct calling paths are intended.

~~~
JoshTriplett
My hope is that WebAssembly will start motivating a set of lower-level APIs,
with higher-level APIs being provided on top of those by WebAssembly
"libraries". JavaScript tends to motivate much higher-level APIs, and you
can't turn high-level APIs into low-level APIs, only the other way around.

~~~
tedmielczarek
This seems orthogonal to WebAssembly. This is already a goal for its own sake
--see the Extensible Web Manifesto.

------
moron4hire
So for now, the idea is to write C++, compile it to ASM.js, translate it into
WebAssembly, GZIP it, transmit it, unGZIP it, then run a polyfill to translate
the WebAssembly into ASM.js?

This sounds absurd. I can't even get through getting Clang, LLVM, and
Emscripten built from source as it is, it's such a house-of-cards with
configuration and dependency settings. Have any of you tried building Chromium
from scratch? I have, on three separate occasions, as I'd like to try to
contribute to WebVR. End result: fewer gigs of free space on my hard drive and
no Chromium from source.

Part of that is my impatience: I'm used to C# and Java, where dependencies are
always dynamically linked, the namespacing keeps everything from colliding,
and the semantics are very easy to follow. But even Node's braindead NPM
dependency manager would be better than the hoops they make you jump through
to build open-source C++ projects. I mean, I just don't get how someone could
have at any point said "yes, this is a good path, we should continue with
this" for all these custom build systems in the wild on these projects.

I could be way off. I'm only just reading the FAQ now and I'm not entirely
sure I understand what has actually been made versus what has been planned.
There seems to be a lot of talk about supporting other languages than C++, but
that's what they said about ASM.js, and where did that go? Is anyone using
ASM.js in production who is not Archive.org and their arcade emulator?

I don't know... I really, really want to like the web browser as a platform.
It has its flaws, but it's the least painful solution of all of the
completely-cross-platform options. But it's hard. Getting harder. Hard enough
I'm starting to wonder if it'd be smarter to develop better deployment
strategies for an existing, better programming language than to try to develop
better programming languages for the browser's existing, better deployment
strategy.

This telephone game being played by translator tools and configuration
management tools and polyfills and frameworks and... the list goes on! This
thing we consider "modern" web development is getting way out of hand. JS's
_strength_ used to be that all you needed was a text editor. Everyone--both
users and developers--can already use it and run it.

If it's just one tool, I'll get over it. But stringing these rickety, half-
implemented tools together into a chain of codependent systems is
unacceptable. It just feels like they're foisting their inability to finish
and properly deploy their work on us. Vagrant recipes are nice, but they
should be a convenience, not a necessity.

Sorry. Good for them. Just finish something already.

~~~
BrendanEich
For years, I've laughed (from skull throne) at the "whyyyy no bytecode" posts
on HN. Now bytecode, still complaints. Still laughing, too.

~~~
moron4hire
I never complained about no bytecode. And I'm not complaining about bytecode
now. I'm complaining about an apparent lack of commitment to bringing any of
these projects to a useful status.

Don't you think developer tools should have good UX, too? Microsoft does, and
Visual Studio just works. Oracle does, and Java and Netbeans just work. Even
setting up Node and NPM was a better overall experience than trying to get
Emscripten working correctly and integrated into my projects.

Emscripten and NaCL are both like 4 years old now. Why hasn't there been
greater adoption of these tools? I postulate it's the bad UX. I mean,
Emscripten only working with VS2010, three whole versions behind latest, is a
pretty good indicator that there is a whole class of users that have just
written it off. Is there any concern for that with WebAssembly?

~~~
BrendanEich
I know, I kid.

Things took a while because vendors had their own prior paths to pursue, while
asm.js had to prove it could get close enough to native perf. (You could say
Mozilla's prior path was JS.)

Tools for JS are pretty good; VS does TypeScript and JS, will do wasm. Firefox
devtools are giving Chrome devtools a run for their (bigger) money.

I think tools are the least of it, while agreeing they make a difference (see
Mandreel with VS integration, vs. Emscripten).

NaCl (PNaCl, you must mean) never went cross browser as such, nor could it.
WebAssembly is the PNaCl end-game, and a pretty good one.

As for Emscripten, it's a huge win that both Unity and Epic (Unreal Engine)
support JS/WebGL as first-class targets. This happened over the last few
years, tools built into the game engines. Doesn't disprove your point, you
could be right! Let's find out.

~~~
EdSharkey
Hey Brendan, thanks for not flipping a huge bird to the web community and
sticking with it.

For myself, I've had very little to complain about web development since '08
or '09\. It became an application platform for me with the emergence of the
canvas tag, and since then it has grown into a full operating environment of
sorts. There have always been awkward and limiting features to the web because
it is such a hodgepodge and I think that's where most of the complaints come
from. But the browser compatibility situation continues to improve, which has
always been my biggest gripe.

I worry a bit about the exploit potential of WebAssembly as more features are
layered atop what Asm.js offers. Don't add too much, okay? ;)

~~~
BrendanEich
Thanks, Ed.

I see any web-scale runtime standard inevitably having versions spread across
the installed base of any server, so prone to the same pressure JS was, which
led to polyfills, graceful degradation, object detection, monkey-patching in
full. People who complain about this are complaining about physics.

You're right to worry about security, which is why the "MVP" for wasm is co-
expressive with asm.js, just faster-to-parse syntax. After that, we must be
even more careful.

------
AndrewDucker
Interestingly, about five years ago, he said he couldn't see this ever
happening:
[https://news.ycombinator.com/item?id=1905291](https://news.ycombinator.com/item?id=1905291)

~~~
BrendanEich
In that comment, I wrote

"A binary encoding of JS ASTs, maybe (arithmetic coders can achieve good
compression; see Ben Livshits' JSZap from MSR, and earlier work by Michael
Franz and Christian Stork at UCI). But this too is just a gleam in my eye, not
on TC39's radar."

And WebAssembly is indeed a compressed AST encoding, not a stack bytecode.
Shhh, don't tell anyone. You can still call it bytecode if you like.

~~~
stcredzero
With an AST representation, one can do interesting things. Everyone could have
their own custom code formatting rules, and it wouldn't have to affect anyone
else. Comments would have to be included in the AST for this to work sanely.

This might even go as far as languages, though for this to work well, the code
would have to cover an intersection of the functionality in all the languages
"rendered" to.

(Haven't watched the presentation yet. I'm in public without headphones.)

------
bhouston
I guess this is in the spirit of NaCL and its bytecode, and the Java VM/Java
bytecode, and the .NET runtime/.NET IR. It makes a lot of sense and I get it
then sort of gets competitive with those efforts as well.

~~~
kevingadd
It does compete with those efforts in a sense, but ideally it is going to
learn from those efforts and provide a powerful cross-browser equivalent to
them instead of just trying to replace them.

------
mhd
Combined with something like e.g. Flipboard's react-canvas, this means we
could bypass _and_ re-implement most of the browser stack...

------
McElroy
[https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...](https://github.com/WebAssembly/design/blob/master/FAQ.md#will-
webassembly-support-view-source-on-the-web) makes me happy as that was the
first concern I had when reading these news :)

------
Murkin
Can someone explain why not just go the JVM or .NET CLR path ?

Both well tested, well executed, great tooling, supported on many platforms,
compilation targets of many existing languages.

Serious question.. is it licensing ?

~~~
azakai
1\. Both the JVM and CLR have different focuses in terms of startup speed,
which matters more on the web than anywhere else (this is one reason Java
failed on the web). JavaScript and WebAssembly are designed to start up
quickly.

2\. If you have both the CLR and a JS engine in the same browser, you have
problems with cross-VM GC cycles and the overhead that causes. That is one
reason why WebKit opposed adding Dart bindings, for example. WebAssembly is
designed to integrate with existing JS VMs.

3\. Both Java and the CLR are open source, but both are patented. Both have
licenses for those patents, but this has been the cause of much debate, as
there are corner cases in those licenses (e.g. if you do not fully implement
all of the VM per the license, you may not fall under its protection). This
could be resolved - all existing patents could be offered up to the public
domain - but I don't see Microsoft or Oracle (and there may be others with
patents) doing so.

------
thomasfoster96
This is pretty awesome, and is a pretty good use of all the effort that's been
going into asm.js

One question though - I found a proposal somewhere on a Mozilla run wiki about
a web API for registering script transpiling/interpreter engines. I've lost
the web address, but if anyone know any more about this is love to see it
rekindled.

~~~
arcatek
I think you're talking about module loaders[1]. I remember seeing on es-
discuss that they have been postponed to ES7.

[1] [https://github.com/lukehoban/es6features#module-
loaders](https://github.com/lukehoban/es6features#module-loaders)

~~~
thomasfoster96
Functionally that's it (didn't realise it'd been rolled into es6 modules
though). Looks like what I was referring to was a third party library:
[https://developer.mozilla.org/en-US/Add-
ons/Code_snippets/Ro...](https://developer.mozilla.org/en-US/Add-
ons/Code_snippets/Rosetta)

------
ncw33
Nice, but I'm still waiting for 64-bit integer arithmetic!

For our use case, what I like about this is that we can continue to use
emscripten and the technology will come to us, rather than requiring app
developers to invest in yet another technology (our switchover from NaCl to
emscripten was very time consuming!)

~~~
BrendanEich
64-bit ints coming along with SIMD in ES7^H2016.

------
haberman
Very very happy to see this.

Politically it appears to be a fantastic collaboration.

Technically it looks like they have really thought through this hard -- if you
look through the post-MVP plans
([https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md))
there are a lot of exciting ideas there. But it's not just pie-in-the-sky
speculation, the amount of detail makes it clear that they have some really
top compiler people who are really rigorously exploring the boundaries of what
can be accomplished inside the web platform (SIMD, threading, GC integration,
tail calls, multiprocess support, etc).

------
jklontz
WebAssembly Backend RFC on the LLVM mailing list:

[http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-
td...](http://llvm.1065342.n5.nabble.com/RFC-WebAssembly-Backend-td82554.html)

------
vmorgulis
This is awesome.

We will probably need a package manager after that (like apt or npm).

A use case could be with ImageMagick, OpenCV, OpenSceneGraph or qemu inside
the browser. All of them are huge and useful projects with many common
dependencies.

------
jacquesm
So, is this the long way around to get us Java Applets all over again?

------
jewel
I hope that someone ports mruby to this. I've come to terms with javascript's
syntax (via coffeescript), but I'd still rather not deal with javascript's
semantics.

~~~
azakai
There is already an mruby port to the web using emscripten. When emscripten
targets wasm, that port will get that for free.

------
paulojreis
> "MS seems to get the modern Web".

This made me laugh, sadly. They _get_ the modern Web because they aren't
winning at _native_ app development.

~~~
tonyedgecombe
I think it's more that native app development isn't winning (except in a few
niches).

------
protomyth
Didn't WMLScript (a subset of Javascript used for WML) have a required byte
code representation?

------
lorddoig
Praise the lord, that was sooner than I expected. Next up: the DOM. Then there
will be peace on Earth.

Does anyone know when all this started? I ask because only 83 days ago Brendan
was on here telling us pretty emphatically that this was a bad idea and would
never happen.

~~~
BrendanEich
Please cite my post from 83 days ago. I think you're misreading it (perhaps
"bytecode" is overloaded). I have good reason to, since I was in on wasm from
the start, which was longer ago than 83 days.

~~~
lorddoig
I didn't intend to ruffle anyone's feathers with that comment. Yes I suppose I
am misreading it, but I don't think I can be blamed for walking away from that
exchange thinking transpilation to JS was the last word on the subject.

Anyway great work man. It's a happy day.

~~~
BrendanEich
Thanks.

Here's Tim Sweeney on diff between "bytecode" and wasm:

[https://twitter.com/TimSweeneyEpic/status/611237145857138688](https://twitter.com/TimSweeneyEpic/status/611237145857138688)

~~~
elwell
Hi Brendan, just hopping on the end of this thread to tell you that I think it
was just disgusting the way that you were boycotted for your donation. It
seemed really hypocritical for them to mistreat you for your opinions.

~~~
bryanlarsen
Maybe we won in the end. If Brendan was spending all his time doing CEO type
stuff, he'd be spending less time giving us awesomeness like this.

~~~
BrendanEich
This was a group effort and I am last, not first. Mainly I played prophet,
peace-maker, coach, bartender.

Not quite the Tetralogy of Tony Stark (genius, billionaire, playboy,
philanthropist) but I'll take it! ;-)

------
McElroy
This page makes Firefox on Android crash.

~~~
crazysim
It crashes in iOS Safari on an iPad Air 2 for me.

------
garfij
I'm curious what the debugging story for this is going to be? Source maps?

~~~
corysama
Yep

[https://github.com/WebAssembly/design/blob/master/FutureFeat...](https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#source-
maps-integration)

------
amelius
Without support for proper threads, web assembly programming feels the same as
programming a Z80 or 6502 back in the 80s.

And no, webworkers don't cut it, because they don't support structural sharing
of immutable data structures in an efficient and flexible way.

~~~
BrendanEich
Tedious to read out-of-date objections. Please do a bit of research and find
out the latest. JS is getting shared memory thread support:

[https://blog.mozilla.org/javascript/2015/02/26/the-path-
to-p...](https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-
javascript/)

This means the MVP wasm likely includes threads (same timeframe, later this
year), and post-MVP wasm can go for full-strength pthreads.

------
andybak
Isomorphic Python here I come...

------
leoc
w00t w00t. This is pretty great overall.

------
UserRights
Is there already a plugin out there that blocks this crap?

------
rockdoe
So this is like PNaCl but targeting the web API and by making it
collaborative, hopefully a real standard allowing independent
reimplementation?

Ironic that Eich is the one to pull the trigger on JS.

~~~
BrendanEich
Pepper was floated on plugin-futures@mozilla.org a long time ago, roc replied
advocating not reinventing web APIs:

[https://mail.mozilla.org/pipermail/plugin-
futures/2010-April...](https://mail.mozilla.org/pipermail/plugin-
futures/2010-April/000088.html)

The collaborative aspect is important, but one side of a coin whose other side
is polyfillability. Nick Bray of the PNaCl team stubbed out Pepper.js more
recently, and JS finally got some SIMD and threads love. It's all converging,
finally. Yay!

~~~
JoshTriplett
There are a few key aspects where web APIs will want to differ between
JavaScript and WebAssembly, though. For instance, some APIs really do need
32-bit and 64-bit integers, _not_ floating-point, and the APIs should be
specified as accepting and returning values of those types. An API tailored to
JavaScript would have to specify how to encode such a number into what
JavaScript can express.

Ditto for data structures (with actual layout, not JavaScript "bag of key-
value properties" objects).

Ultimately, I'm hoping new web APIs will be specified as a WebAssembly ABI,
without taking JavaScript into account; the JavaScript interface to those APIs
can be responsible for questions like "how do I call a function specified as
taking a 64-bit unsigned integer?".

~~~
BrendanEich
JS is getting int64 and uint64, so you need a better example, like zero-cost
exceptions, dynamic linking, call/cc (listed in my post).

~~~
JoshTriplett
> JS is getting int64 and uint64

It's a fine example for today's browsers that don't have those. Fixing that
for future JavaScript doesn't help APIs being designed today, or existing
APIs. And it doesn't invalidate the point that JavaScript limitations should
not be web limitations.

For instance, how about efficient structs with defined in-memory layout?

Targeting web APIs to WebAssembly means that the web can tell JavaScript to
keep up, rather than JavaScript telling the web to wait up.

~~~
BrendanEich
Wait, how does wasm help APIs being designed today?

Please use the same yardstick when comparing.

Important that JS grow too, including SIMD, shared memory, value types
including 64-bit int. Does not alter the case for wasm, per the FAQ: parse
time win soon, divergence to relieve JS from serving two masters in longer
run.

~~~
JoshTriplett
I'm using the same yardstick, relative to the baseline implementation of each
language. APIs won't be able to natively target WebAssembly until browsers
have native support for it. However, once browsers natively support
WebAssembly, there won't need to be a "today's WebAssembly" versus "tomorrow's
WebAssembly" issue; interesting new features belong in the languages
_targeting_ WebAssembly, with WebAssembly itself handling things like "how do
we efficiently generate SIMD instructions on every target platform". Questions
like "what datatypes do we support" become uninteresting; the answer is
"whatever both ends of an ABI can agree on".

~~~
BrendanEich
You wrote

"Fixing that for future JavaScript doesn't help APIs being designed today, or
existing APIs."

and I asked

"Wait, how does wasm help APIs being designed today?"

Your different yardstick is the shift from "today" to "future". WebAsm that is
a super of JS is in the future, past the polyfill era of co-expressiveness.
Fault JS today for lacking int64 by the same (temporal) yardstick should fault
wasm today.

In general we agree, but you are arguing carelessly. There is no essential
difference between int64 for JS in the future, and int64-equipped wasm in the
future. Both are in the future.

The solid ground on which to argue is where browsers all update to support
wasm, whose syntax and extension model(s) stabilize, and _then_ wasm can run
ahead of JS. But it'll be a managed standards, so don't expect a huge
iteration-time win. It'll be good for both JS and wasm in that farther future
to decouple concerns, I agree.

Are we done yet?

~~~
JoshTriplett
I'm talking about the meta-problem here: APIs designed today have to care
about today's JavaScript semantics, which are high-level JavaScript-specific
constraints. APIs designed for browsers with native wasm support care about
the semantics of wasm, but those semantics are language-agnostic. APIs should
be designed based on a language-agnostic ABI, not based on JavaScript. That's
the world I'm looking forward to.

Even the planned future ABI for interoperable dynamic linking is a guideline;
any caller and callee that agree can use a different, extended ABI.

> The solid ground on which to argue is where browsers all update to support
> wasm, whose syntax and extension model(s) stabilize, and then wasm can run
> ahead of JS.

Of course, and that's exactly the world I'm talking about.

> But it'll be a managed standards, so don't expect a huge iteration-time win.

WebAssembly is in a very critical way _smaller_ than JavaScript, so its
iteration time is less important. wasm iterations will be important for
performance (to provide constructs that will efficiently translate to the
native machine code you or a compiler would have written), and we'll need new
APIs for things like thread-spawning, but new language features and functions
using those features won't require any changes to wasm.

> Are we done yet?

By all means let's stop violently agreeing with each other. :) Thanks for
working on WebAssembly; I look forward to using it.

~~~
Touche
> APIs should be designed based on a language-agnostic ABI, not based on
> JavaScript.

Has there ever been such a thing?

~~~
JoshTriplett
[http://x86-64.org/documentation/abi.pdf](http://x86-64.org/documentation/abi.pdf)
, for one example.

------
joosters
To an end user, how is this a different experience from flash? You browse to a
website and must execute binary blobs in order to view the site.

Even worse, it's like Flash but where the flash 'plugin' has been written from
scratch by each web browser, giving us endless possibilities of
incompatibilities which are a nightmare to fix.

