
WebAssembly: a binary format for the web - olalonde
http://www.2ality.com/2015/06/web-assembly.html
======
zmmmmm
As laudable as the goal of improving performance is, I hope this never takes
off. Why? Because it will take about 5 minutes from 90% of the web to go from
open, transparent, easily reverse engineerable source code to essentially
giant blobs of secret binary code. People will pay lip service to performance
but 99% of the reason that web sites will implement this will be to cover up
their code, keep secret their implementation techniques and technologies, hide
poor code and poor security.

I honestly think that one of the key ingredients to the success of the web is
that just about any web page you can see, just about anyone with modest
knowledge can trivially work out how it was done. It is only an accident of
history that it worked out that way. But the effect has been to spread
knowledge far and wide and it has greatly contributed to the success of web
technologies. Furthermore, I can easily look at the source code for my bank
web site or any web site I want to trust and get a good idea of how solid
their implementation is. Yes I can't inspect the back end, but a whole slice
of front-end security issues are easy for me to check for myself. This kind of
scrutiny will get a good bit harder if web assembly becomes adopted.

~~~
13years
Yet, isn't much of the web already unreadable due to minification of JS
source?

~~~
Mikushi
If you think minification does anything to prevent anyone from reading it you
are mistaken. Is it harder? Yes. Impossible, not even close, just annoying.
I've reversed engineer JS libraries with 20K LOC that were minified and
uglified in less than a day, hardly what I consider a hurdle.

Now, to have worked with asm.js recently, that's a whole different ball game.
That is unreadable, at least without spending copious amounts of time on it
and having a deep understanding of asm.js to be able to read it.

~~~
Touche
What do you get out of reading some random website's minified javascript?

~~~
tracker1
Sometimes it's just the curiuosity of "how did they do that?" In general, one
doesn't go around looking at the code everywhere, but on more than one
occassion I've looked into something to figure out how something was done, or
why it's broken in my browser (much more common in early Firebird^b^b^b^bfox).

On the one hand, I hope it gives a real build target for Rust and Go... on the
other, I hope things don't get too obfuscated in practice.

------
Animats
From Java applets to Java applets in twenty years.

~~~
haberman
Java applets were slow to load because fast loading was never made a priority.
WebAssembly is prioritizing small size and fast loading.

Java Applets were completely isolated from the surrounding web page, and vice-
versa. I tried writing XEyes as a Java Applet back in the day, but the
eyeballs could only follow the cursor while the cursor was directly on top of
the applet's rectangle. WebAssembly operates on the single unified DOM and its
event model.

Because it uses the DOM, the text and widgets are real. The text is
selectable, looks like regular text, etc. Java Applets had their own
GUI/widgeting system that looked bad and behaved differently.

~~~
wbillingsley
There was a JavaScript to Java bridge in most browsers -- you could simply
write a JS event handler that called a public API in your applet.

Before XMLHttpRequest became reliable across browsers, a fairly common trick
was to use a 1 pixel Java applet to do the asynchronous calls to the server,
and then call back out to JavaScript to manipulate the DOM.

Java only "behaved differently" if you wanted your applet to paint a square of
the screen. Which was more about the problem that browsers also didn't support
SVG, so if you wanted an interactive diagram you had to isolate yourself from
HTML.

~~~
asdfologist
Why was this downvoted? I found this quite informative.

------
huuu
Posted some time ago, a .NET implementation and discussion:

[https://github.com/WebAssembly/ilwasm](https://github.com/WebAssembly/ilwasm)

[https://news.ycombinator.com/item?id=10162793](https://news.ycombinator.com/item?id=10162793)

I also have to think about the new image file format posted some time ago:
FLIF ([http://flif.info/](http://flif.info/)). With WebAssembly you could
implement this in the browser by just embedding a lib. No need to wait for the
vendors to support it.

------
dbpokorny
As far as the intersection of (innovation in web technology) and (innovation
in programming languages) is concerned, I think the focus on performance is
like going backwards in time, perhaps to the mid 90s.

I feel like these innovations are being turned into a kind of "social media
spectacle" with relatively little discussion of what innovation really means
in this context.

For example: I don't understand why Python, JavaScript, Java, Ruby, and so on
have not delivered tools that ease the path for those who wish to write
applications designed to run code from untrusted sources. I think this would
make the web a lot more competitive and overall healthier as an independent
institution.

(Yes I understand JavaScript is code from an untrusted source that runs in a
sandbox on your computer, the browser client; in this context I'm referring to
the ability of a JavaScript web app to load objects (from a JavaScript source
code file hosted on ANY domain, in defiance of XSS dogma) which the browser
client guarantees does not exceed the bounds of a specified "sandbox" built to
spec, a "security envelope" for loading and evaluating code. For example the
ability to tell the client, "execute procedure P with arguments A, but kill it
if it runs for more than 0.5 seconds of CPU time or allocates more than 500 MB
of memory" or "only load this source code as long as the global variables it
uses is on this list: ..., the names of properties is uses is on this list:
..., and it refrains from using the following syntactic keywords: ...)

Python put up a warning against its own "restricted execution" a long time
ago:
[https://docs.python.org/2/library/restricted.html](https://docs.python.org/2/library/restricted.html)

In the age of GitHub, why is there no interest in building infrastructure that
allows programmers to define such "security envelopes" for JavaScript, Python,
C, and so on and create systems which are composed of mutually distrusting
modules which would, I think, simplify reasoning about their security
characteristics?

~~~
haberman
> For example: I don't understand why Python, JavaScript, Java, Ruby, and so
> on have not delivered tools that ease the path for those who wish to write
> applications designed to run code from untrusted sources.

Probably because it is stupidly difficult to do robustly, especially when the
language and standard libraries weren't originally designed to do that.

Lua is perhaps best positioned for this given how tightly you can lock it down
(you can remove the 'require' function that loads other modules). But even
this is considered not robustly secure against untrusted code.

[http://lua-users.org/wiki/SandBoxes](http://lua-users.org/wiki/SandBoxes)

~~~
david_ar
I'd argue Haskell has the best support for this:
[http://safehaskell.scs.stanford.edu](http://safehaskell.scs.stanford.edu)

~~~
codygman
Example:

[http://tryhaskell.org/](http://tryhaskell.org/)

source:

[https://github.com/chrisdone/tryhaskell](https://github.com/chrisdone/tryhaskell)

For those that just want to see the sandboxing part, I think most of the magic
is in mueval but I could be wrong:

[https://github.com/gwern/mueval](https://github.com/gwern/mueval)

------
corysama
A good talk from a week ago on WebAssembly:
[https://www.youtube.com/watch?v=NhAPPQqKCi8](https://www.youtube.com/watch?v=NhAPPQqKCi8)

~~~
mstade
Merits of the contents aside, the guy presenting has a very judgmental and
condescending tone making it difficult to appreciate what he's actually
saying. Saying things like "this doesn't look anything like a programming
language, especially if you're coming from the javascript world" or "I will
explain shared memory multi-threading in a bit, especially for the front end
developers" really doesn't help. I find statements like that offensive, and
detrimental to getting good conversations going. I've not finished watching
that presentation on these grounds, and I'm not sure I will. It's not out of
principle either, but simply because I get too annoyed to continue.

For the record, I identify myself as a software engineer. These days I mostly
do front end development, but I have written code in many languages and
contexts (asm, javascript, c, python, vb, whatever fits) and been well
remunerated for it. I find the front/back/native/whatever splits to be silly,
probably fueled by trying to make more efficient job listings. Fine that HR
folks do this, but as engineers we should know better.

~~~
ZenoArrow
So you're a full stack developer. Some coders are only familiar with their
domain. For example, most of my coding experience has been backend database
scripting stuff, I have very little familiarity with the front end.

I don't see why you would get offended, he was talking to the specialists, not
the generalists. You have to understand there's no shame in not knowing
something outside your domain. For example, if you've never done AI
programming before, would you be offended if an experienced AI coder skipped
over some details in order to provide a more friendly introduction? It's not
meant as an insult, it's not a reflection on your capability to learn about
it, but rather it could be based on a consideration that you may not have
taken the time to learn about it yet.

~~~
roel_v
A good communicator is careful in his phrasing and keeps 'the human factor' in
mind. It's not something that engineers are usually willing to admit or cater
to, of course, but doesn't make it less true.

As a corollary, this is the same point that people asking 'why aren't
engineers paid better' are really asking about, but can't or won't see...

~~~
ZenoArrow
Engineers don't like being talked down too, but if something is outside your
field then simplifying is still pragmatic, regardless if you have extensive
knowledge in other fields.

Let's put it like this, if I was the guy giving the talk, and I knew I'd get
this reaction, I would do nothing differently. I'm not going to waste my time
pandering to people who would take a tech talk personally. I don't care if
managers get paid more, if they want to water down their words to ensure no
offence to anyone, they're welcome to take that burden.

~~~
mstade
It's not about pandering, but about being inclusive in an educational setting.
You're giving a talk so as to inform people, not imply they are lesser in some
way. To concretize, consider replacing "the front-end developers" with "those
unfamiliar with the concept":

> I will explain shared memory multi-threading in a bit, especially for those
> unfamiliar with the concept.

Versus the condescending:

> I will explain shared memory multi-threading in a bit, especially for the
> front-end developers.

Tiny change, makes all the difference. Be inclusive; don't be condescending.

------
omphalos
It would be nice if the ability to reason about execution timings were one of
the design goals of WebAssembly, because this could make it safer to port to
crypto to the web.

------
jgalt212
If the new way forward allows everyone distribute unreadable binary instead of
readable, or de-obfuscatable, JavaScript, I think this definitely bad for open
source and bad for innovation which depends upon stuff like: "oh, now I see
how that did that. I think I can apply that technique to something else".

Of course, people can release their js, python, java, et al that compiles down
to WebAssembly, but because you are not forced too, I do not think most will.

~~~
mrec
How is this any worse than minified Javascript? Without meaningful names or
comments you're not much better off than you would be with WASM+disassembler.

~~~
roel_v
It's the difference between a 'java decompiler' and a 'c++ decompiler'. Which
is significant enough for there to be a market for commercial 'java
obfuscators', but not for 'c++ obfuscators'.

------
rasz_pl
can you go back to source code from WebAssembly binary? I dont want a web that
serves me obfuscated binary blobs.

~~~
RussianCow
No, but one of the goals of WebAssembly is to have a textual representation,
so in theory you could still View Source. Not sure how that'll work out in
practice, though.

~~~
userbinator
In practice, I think most browsers won't include a "disassembler", under the
justification that most users won't need it; I can see "View Source"
unfortunately going that way too.

What's wrong with that argument is the fact that although _most_ users don't
need it, it's an excellent way for those interested to explore into and find
out how things work, and essentially get into web development with nearly no
effort. If this trend continues, in the future when browsers become nothing
more than dumbed-down interactive TVs, I think there will be very few, if any,
web developers who started out of their own interest and exploration instead
of solely thinking of it as a profession, and that's a really bad thing. (For
the corporations who want to take control, this could be viewed as a good
thing - why would they want to encourage independent thought and exploration
when they could have dogmatic obedience?)

Computing systems are becoming more closed and proprietary, and this will be a
_big_ step backwards in terms of openness of the Web that lead to its growth
and freedom in the first place.

~~~
pjmlp
When I got into computers there wasn't any view source button.

We had to buy magazines and books to view any source.

Still lots of us got interested and a few guys managed to build the initial
web infrastructure without a view source button.

~~~
adrianN
Back in my day we didn't have compilers, we twiddled the switches until the
machines did what we want. Compilers just allow sub-par programmers to write
code, we should better abolish them.

~~~
pjmlp
That has nothing to do with "view source" button.

I also doubt you are old enough to have used something like the Altair 8800 or
have built your own computer from Elektor schematics.

------
kmicklas
Why does everything about WebAssembly make such a big deal about it being AST
based rather than a stack or register machine? Sure this is a meaningful
technical difference but I don't see why it's really a "selling point".

~~~
pinealservo
Here are some arguments from the guys who did something like this before for
Oberon: ftp://ftp.cis.upenn.edu/pub/cis700/public_html/papers/Franz97b.pdf

To summarize:

1\. Much smaller representation, which will mean faster download times 2\.
More control-flow structure retained, which means less needs to be rebuilt by
JIT-compilers. 3\. As a corollary of #2, we get easier and more helpful
'decompiling' of code blobs 4\. Another corollary of #2: easier analysis for
safety properties

------
jacquesm
Write once, run _anywhere_.

------
androi
Hi i have also found one good example here ... <a
href="[http://androidexample.com/Global_Variable_Or_Application_Con...](http://androidexample.com/Global_Variable_Or_Application_Context)
_Variable_-_Android_Example
/index.php?view=article_discription&aid=114&aaid=136">[http://androidexample.com](http://androidexample.com)
/Global_Variable_Or _Application_Context_Variable_-_Android_Example/
index.php?view=article_discription&aid=114&aaid=136</a>

------
masswerk
Hm – Client-side web programming is all about resource management. I can't
see, how cross-compiled C++ code that originated for a completely other
platform with object code in the MBs range will do a decent job. And even, if
this is not the original idea of WebAssembly, this is sure to come.

(We've seen similar with emscripten: As much as I love it as an experiment,
it's highly problematic in production.)

And of course, as others have already pointed out, it's likely to ruin the
vision of the web as a mosaic of just a few trivial technologies that can be
investigated with modest knowledge. (Compare the comment by zmmmmm.)

------
no1youknowz
I am someone who makes a living having a SaaS that clients use.

I've had clients who have tried to "clone" my work, but eventually come back
because they couldn't figure out the backend code or scale.

I would love something that is the equivalent of installing an app on a phone,
that is using a compiled app in a browser. Where the source can't be viewed.

Even better, if I can give a rich UX. By having access to the system.

Yes, I believe in some very small cases this will be welcomed. Otherwise, I
think for everyone like 95% of the web, html, js, css, etc, will see be the
way to go.

~~~
nv-vn
So even though they can't succeed at 'stealing' your job by copying the code
you still don't want them to have access?

~~~
no1youknowz
I don't have a job. I offer a service to clients. I get paid when they use my
software.

If they created their own software, they would not have to pay me any money.
So without money, I have to go on welfare.

You get my point?

No, I don't want any of my clients to get access to my source code. I am not a
giant corporation like redhat, google, oracle or other company that open
sources it's software and then sells support or other services.

I'm a small company, who with more clients. Is hoping to them employ a small
workforce and grow the company.

------
JoshMnem
What will this mean for blocking ads and certain trackers? If the source of
the page isn't viewable, how will users know what the code is doing?

~~~
pritambaral
I'm sure you can still inspect the DOM and the network calls made by the page.
DOMs, URLs, and HTTP aren't going anywhere.

And the current ad-blockers almost never go through the source code of a
script, only the src and the URLs

------
yjgyhj
What does this mean for compile-to-js languages, like Clojurescript, Elm (and
ES2015 one might argue)?

~~~
corysama
So far, not much. Clojurescript, Elm and most others assume that JS is taking
care of garbage collection for them. Meanwhile, WebAssembly so far does not
include GC support. If someone were to implement a custom GC for Elm on top of
wasm's "here's a big array of bytes" memory model, it would be very
interesting indeed. But, at the moment wasm is primarily a target for C/C++.

~~~
MichaelGG
That's rather weak. How do you interop with the DOM? Explicit FFI? Are there
plans to make WebAssembly catch up with the last several decades? There's no
reason we can't have a proper IL like .Net or even Java at worst.

~~~
corysama
Yep, FFI. GC/DOM/Web API integration is in the eventual plans.
[https://github.com/WebAssembly/design/blob/master/GC.md](https://github.com/WebAssembly/design/blob/master/GC.md)

You want .NET on bare metal? Implement it on x64, ARM, MIPs and maybe PPC. You
want .NET in the browser, implement it on wasm. You want Java in the browser,
implement it on wasm. You want BEAM in the browser, implement it on wasm. You
want Parrot in the browser, implement it on wasm. What you are not going to do
is to get Google, Apple, Mozilla and Microsoft to all agree on any of those
ILs.

------
ilaksh
The big advantage for web assembly is that is really language agnostic
(besides the performance).

------
spo81rty
So could someone theoretically make flash or silverlight work via this?

~~~
elcritch
Theoretically you can make those work in JavaScript. The performance might
even be ok, but the limitations would still be the huge effort in reverse
engineering flash or silver light code and features and secondly the browser
sandbox policies which AFAIK aren't changed for WASM.

~~~
icebraining
It's not just a theory, Mozilla has already implemented Flash in JS:
[https://github.com/mozilla/shumway](https://github.com/mozilla/shumway)

------
zobzu
The future! serve binaries instead of web pages!

~~~
pekk
Web pages are already a far cry from human-readable semantic markup. That's
not a hill worth dying on.

~~~
zobzu
careful what you wish for

------
alkonaut
I see a future in which I write apps that run JS for the DOM, but I need to
worry about neither JS nor the DOM. Glorious.

------
denniskane
Okay, seriously.

The _only_ possible benefit that this technology could have for the planet is
to give Brendan Eich a reason to run yet another one of those video-game-
inside-of-a-video-game demos at another one of those JS conferences that
frontend devs go so nuts about.

Except this time, there will be yet _another_ video game inside of that inner
video game!

------
luancestari
Awesome, I would love to see an helloworld application hosted in github

------
jtwebman
I hope to see so the developers that don't like JavaScript stop writing bad
JavaScript and just write it in whatever class based type based system they
want instead of adding classes and types to Javascript.

~~~
runn1ng
But adding type system to JavaScript - as Facebook has done with Flow - and
class system - as in ES6 - actually makes complex JavaScript better and
easier...

~~~
ilaksh
I have literally heard the argument that React basically doesn't count as OOP
anymore because they are now emphasizing 'functional' Javascript, even though
they still rely on the main base class.

~~~
runn1ng
I don't really know. I use Flow, but I don't use React.

------
drvortex
Binary blobs on the web? Have we learnt nothing from ActiveX?

~~~
yuhong
ActiveX had full access to the user's system.

------
denniskane
"Why should WebAssembly succeed where previous attempts (such as Adobe Flash
and Google Portable Native Client) have failed?"

Failed????

Excuse me, I haven't even BEGUN to scratch the surface of the awesomeness that
is pnacl in my own project!

~~~
Blackthorn
If Adobe Flash was a failure, I only hope I can fail as well and as strongly
in my life...

~~~
denniskane
Yeah, I was referring to pnacl (as in Portable Native Client), but that is a
very good point about a technology that is obviously still going strong all
these years later.

------
hannob
I haven't looked at WebAssembly in Detail, but my feeling and worry is that
this is a can of worms for security issues.

Javascript wasn't designed with security in mind and it has taken us decades
to understand what implications that had (and we haven't really fixed them
yet). The security implications for WebAssembly will be different, but I'm
almost certain there will be a lot. (pnacl already introduced some quite
unexpected issues, e.g. allowing control over cache flushes and thus making
rowhammer attacks easier.)

Given that neither the linked text nor the FAQ they have does even mention and
discuss that I'm even more worried.

~~~
pcwalton
> The security implications for WebAssembly will be different, but I'm almost
> certain there will be a lot.

What can you do today in Web Assembly that you can't already do in asm.js?

~~~
hackcasual
Nothing. WebAssembly in its current implementation is basically a binary
representation of asm.js.

------
einrealist
The major flaw in WebAssembly is the byte code itself. We will end up in a
compatibility hell, because of course the specification will change. And there
will be several implementations of WebAssembly, which will have their own
quirks and flaws.

So the WebAssembly future will look like this: You will compile into
WebAssembly multiple times, for different versions and implementations and you
will need to deliver the correct artifacts to the clients.

The reason, the web still works is that everything is shipped to the client in
source. And the client will then interpret and compile everything according to
its capabilities.

WebAssembly will probably never gain traction because of this reality.

