
WebAssembly Browser Preview - zmodem
http://v8project.blogspot.com/2016/10/webassembly-browser-preview.html
======
sunfish
The big news here is coordinated announcements from _multiple_ browsers:

[https://blogs.windows.com/msedgedev/2016/10/31/webassembly-b...](https://blogs.windows.com/msedgedev/2016/10/31/webassembly-
browser-preview/)

[https://hacks.mozilla.org/2016/10/webassembly-browser-
previe...](https://hacks.mozilla.org/2016/10/webassembly-browser-preview)

[http://v8project.blogspot.com/2016/10/webassembly-browser-
pr...](http://v8project.blogspot.com/2016/10/webassembly-browser-preview.html)

[edited to make links clickable]

~~~
kibwen
I've been incredibly impressed at the level of coordination that we've seen
from browser vendors on WASM. I know that they've all been working together
behind the scenes for decades now on various initiatives, but I can't remember
the last time they've all been so publicly supportive of each other as they
are here.

~~~
wlesieutre
WebKit is notably absent from the announcements. It's marked "In Development"
though!

[https://webkit.org/status/#specification-
webassembly](https://webkit.org/status/#specification-webassembly)

~~~
SiVal
It's not WebKit that matters; it's Apple. Apple was also conspicuously absent
from the original wasm announcement. Brendan Eich announced (paraphrased),
"This wouldn't work without all browser makers buying in, and all of them are
today announcing their intention to support wasm, including..." [insert a list
of all the companies EXCEPT Apple].

Asked about the missing Apple, he responded that he was sure they were on
board but hadn't submitted their written statement by his deadline. I asked
why he would assume they were going to publicly commit to it if they hadn't.
It would have taken a one-line statement.

He got very snippy and said that they were obviously _just a bit busy_ getting
ready for one of their regular public performances (maybe WWDC, I don't
remember.) Yeah, sure, that must be it.

Their show came and went, and I must have missed the announcement. More shows
came and went. If Apple ever publicly committed to supporting wasm, as all the
other companies did on day one, I haven't seen it, but maybe they eventually
did. (It would be easy for me to miss, so I'm seriously asking here.) Is
anyone aware of any link to that public announcement of support, the one that
we would have seen on day one if Apple hadn't been so busy?

If not, then there is another possibility. There are Apple people contributing
to the wasm technology, both the development of the spec and the
implementation in WebKit (I believe, but correct me if I'm wrong.) That would
give Apple the _option_ of supporting wasm if they ever chose to do so. I'm
sure they want that option. And no public announcement of support means they
are hanging on to their option to exercise their iOS/Safari veto power over
this significant advance for open web apps (vs. vendor-controlled native
apps).

~~~
BrendanEich
Sorry, I don't recall being snippy, but I do recall you were pushing for me to
"prove a negative", which is a fallacy. I can't prove Apple is committed to
supporting WebAssembly and speak for them. But if you follow their bugzilla,
you can see that the

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

dependencies are getting attention. Note also who is assigned to some of the
recent ones: JF Bastien, formerly of Google (long-time PNaCl team member).

I may also have been unwilling to put people I know at Apple, with whom I'd
spoken about WebAssembly in person at CurryOn in Prague (July 2015), on the
spot. But suffice to say they're keen on WebAssembly and everything looks as
on track as it can be, for a stealthy prima-donna company like Apple!

~~~
warent
The bugzilla is nice, thanks, but you completely lost me at "stealthy prima
donna"...

~~~
BrendanEich
Not an oxymoron, note well: the best prima donnas work their PR on their
schedule, and suppress all others' attempts to reveal their secrets. Just like
ol' Shiny!

------
titzer
Hello from the Chrome/V8 side of this announcement!

We'd like to say that we're incredibly excited to keep moving WebAssembly
forward, and that's in large part due to the amazingly collaborative model
that all of the vendors have put together through interpersonal relationships
and shared vision.

Please scrutinize and comment on the design, bang on the tools, and give us
feedback! Maybe try writing a codegen or tinkering with the existing tools.
Try porting an app or a game. If all goes well, this is what the vendors have
agreed to ship at the beginning of next year, so we want to be absolutely sure
that it's something solid that others can build on top of.

This is also not the end of the evolution for WebAssembly, since there is a
pipeline of features planned that go beyond the MVP (minimal viable product),
well into next year and after. The web and the working group is the place to
experiment with and perfect those details going forward.

It's an exciting time for the future of the web!

Thanks, \- TL on the V8 side

~~~
bluejekyll
Thanks for all the hard work! This is really excellent.

I know this is marked as "future", but is there any progress on exposing the
DOM? That's something I'm personally really excited for.

~~~
titzer
It's something we've discussed on various occasions, usually after in-person
meetings. So far it has not been the highest priority additional feature,
since one can always FFI to JS in the mean time, so that gives us some
breathing room to see how usage patterns develop before committing to a
potentially large new API surface. A step along that path is just the ability
to refer to JS and other objects directly through opaque typed references, and
that is more likely to happen sooner rather than later.

------
kibwen
Let's not let this announcement overshadow what's really important:
bikeshedding over the official WebAssembly logo
[https://github.com/WebAssembly/design/issues/112](https://github.com/WebAssembly/design/issues/112)
:)

~~~
moron4hire
LOL, for how smart we like to think we are, we are incredibly stupid people.
Who _doesn 't_ know about bikeshedding by now? Yet we still do it.

Logos should never be created by the community. The community should always
appoint a logo dictator and either accept their selection or overthrow them
and appoint a new dictator.

~~~
ufmace
That's the thing about bikeshedding - it's easy to learn what it is. It's hard
to actually stop contributing to it yourself, and often even harder to lead a
team out of doing it.

~~~
jasonm23
Come my people! Let me lead you out of the darkness, away from your bike
shedding ways!

But first, I'd like to know what you all think about my choice of shoes. Are
they the right shade of brown?

We can have a round table meeting to discuss it next Friday.

------
pettou
Please, does anyone know:

\- Why the chose stack-based VM, rather than register-based one?

\- I see the docs mention Float128 type, is this a real possibility? What it
their opinion on having Float128?

\- there doesn't seem to be any support for ADC instruction ("add with carry")
which would be very useful for implementing multi-precision numeric types. Are
the plans to support ADC and the like or not? How to implement, say BigInt,
with WebAssembly?

\- maybe I misunderstood but when adding two integers result in an overflow,
does it trigger the "trap"? I mean, lot of time (e.g. modular arithmetic) one
does what fast "wrap around" (i.e. modulo 2^INT_SIZE) in integer types. Is
this behaviour (of C) going to stay in WebAssembly?

~~~
wahern
Signed integers in C don't wrap around. That's undefined behavior. Unsigned
integers behave modulo 2^n, so if you want wrap around in C you should be
using unsigned integers. Any C compiler to WebAssembly would have to implement
unsigned behavior regardless of the semantics of WebAssembly's native unsigned
operations.

For information on the semantics of WebAssembly arithmetic, see

[https://github.com/WebAssembly/design/blob/master/Semantics....](https://github.com/WebAssembly/design/blob/master/Semantics.md#32-bit-
integer-operators)

For other information about WebAssembly start here

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

------
rayalez
What do you guys think is the best-case scenario for this project?

Like if everything goes well, how do you imagine it will affect the web in
5-10 years? What are we going to be able to do with it?

~~~
c-smile
As soon as this will be in place:

1\. You will not see obfuscated (a.k.a.) uglified JavaScripts anymore.
Everything will be compiled into bytecodes.

2\. But don't worry, you will see bunch of webDisAssembly tools.

3\. You will not see blog posts "How bad is that JavaScript" anymore.

4\. But do expect to see "How bad is WebAssembly" though.

5\. "Vanilla JavaScript" camp may have "Vanilla WebAssembly" banners on some
tents.

6\. You will not see anymore those ugly attempts to write Ray Tracer in JS.

7\. Each framework will finally have its own programming language. Most
advanced of them will change language on month basis, like Angular35 will use
Rust build 3234.23.400. Moving asymptotically close to the Web Holy Grail.

8\. Browser API will be decomposed to bare-bone state,

8.1 you will see immediate mode drawing a la WM_PAINT drawing style. Finally.

8.2 you will see CSS extendedable by custom layout managers and properties.

8.3 CSS modular system will reach its eternal ideal. Instead of them writing
specs for us each our site will have its own CSS modules.

At the end: each team will write their own browser - FF, GC, IE will just
provide WebAssembly loader means. Everything else will be just loadable.

So at the end you will get good Java Applet idea with User Agent exposing pure
AWT alike primitives. With the browser as such a ClassLoader thing.

~~~
ethbro
As someone with a better grasp on this, care to comment on a wasm-based future
and the idea of a browser essentially turning into a network-driven
hypervisor?

I realize the initial wasm spec doesn't seem to be aiming at that level of
complexity, but I'm curious if/why repeated extensions of it won't move us in
that direction.

~~~
indolering
The original vision of the browser was a cross-platform vehicle for delivering
applications over the network. It's not just an idea, it was always the
explicit goal and WASM is the last piece of the puzzle.

Java was supposed to be key to that goal, but it didn't match the capabilities
of the network and processing speed of the time. As painful as HTML, CSS, and
JavaScript are to use, they actually worked.

Compile-to-JS, NaCL, and asm.js culminated in a realistic blueprint for how to
build a low-level network-oriented runtime. Combined with increases to network
speed (the average webpage is the size of the original DOOM) WASM is finally
doable.

On the plus side, holy shit we can do (almost) anything! WASM will also mean
outside money pumped into improving the browser runtime, such as Ethereum's
migration to WASM.

Some of the parent comment is tongue-in-cheek, but you can already see one
downside: fragmentation. Any good API gets screwed up in committee, so we end
up with the most bare-bones and verbose implementation possible
(WebComponents, IndexedDB, etc). Since they are so painful to use we end up
importing 3rd party libraries which entails incompatibility. The content
itself also becomes more opaque, as we can't just parse HTML to figure out the
contents of the page.

That being said, holy-shit we can do anything!

~~~
ZenoArrow
> "The original vision of the browser was a cross-platform vehicle for
> delivering applications over the network."

The original vision for the browser was as a vehicle for browsing through
interlinked documents. Web apps were an afterthought.

------
st3fan
Why speculate about what Apple is doing if you can just go look at the WebKit
change history.

Search for WebAssembly on [https://trac.webkit.org](https://trac.webkit.org)
and you can see that there is a lot of work happening.

The most recent commit being "WebAssembly API: implement Instance" \-
[https://trac.webkit.org/changeset/207929](https://trac.webkit.org/changeset/207929)

So yeah it looks like it is not finished. But it also looks like they are
investing a lot of engineering time in this feature as we speak.

------
jim-greer
I really wish Adobe would write a Flash runtime in WebAssembly. There are tens
of thousands of great Flash games that are unplayable in modern browsers...
Sure, you could rewrite them in js, but no one is going to.

~~~
IvanK_net
Three years ago, I had an idea to write my own Flash Player in Javascript, but
I was too lazy to start working on it.

Today, we have PDF.js, emulators of gaming consoles, or even emulators of a
whole x86 computer, which can run Windows OS. I believe that "SWF interpreter"
in Javascript can run pretty fast. The specification is free available online.

The only problem I see is, that in Flash, you can create TCP / UDP sockets,
which is not possible in a web environment.

~~~
jim-greer
There are some other things you can't do from the browser in addition to
sockets. Full screen, camera, and microphone. But most games don't use that
stuff.

~~~
od14
This is not true, all of the things you mentioned are possible in modern
browsers and are being standardized. However some of them require permission
from the user.

(1) Full screen: [https://developer.mozilla.org/en-
US/docs/Web/API/Fullscreen_...](https://developer.mozilla.org/en-
US/docs/Web/API/Fullscreen_API)

(2) Camera + Microphone: [https://developer.mozilla.org/en-
US/docs/Web/API/MediaDevice...](https://developer.mozilla.org/en-
US/docs/Web/API/MediaDevices)

------
diamondo25
I haven't really looked into the implementation, but won't this be yet another
possible way for getting out of the V8 sandbox and be able to execute code and
thus be able to exploit? I recall exploits using typed arrays for code
execution before, because they can contain raw assembly in a very low-level
style (e.g a plain char array in C++)...

~~~
littlegreenb18
This is not machine assembly. Its bytecode, everything still lives in the
browser sandbox.

~~~
chillydawg
Where the sandbox now has a much larger attack surface as it has to implement
a whole new virtual machine to run the webasm.

~~~
gsnedders
Nobody's writing a whole new VM to run it; everyone is just treating it as
another input format to their JS VM.

~~~
icefox
[https://github.com/AndrewScheidecker/WAVM](https://github.com/AndrewScheidecker/WAVM)

~~~
gsnedders
Given the context, what browser is that going into? How is that relevant to
browser sandboxing?

~~~
icefox
Ah yes within the browser space the various companies are just putting web
assembly in/alongside the existing javascript engines. WAVM was just an
example of a whole new vm that isn't for a browser, but does run webassembly.

~~~
gsnedders
Yeah; I probably should've been more explicit in my original comment: there's
definitely new VMs being written for WASM, but none are currently expecting to
go into browsers, hence concerns about sandbox escapes from browsers aren't
affected by them.

------
mevile
I thought web assembly compiled to JavaScript, but it doesn't look like that's
so. It looks like a binary format. I think that's great if so. Finally we can
expand beyond JavaScript on front-end development.

~~~
maga
Yes, you're right. This can allow to avoid JS in browser altogether one day.

As a hardcore JavaScript developer I welcome this tech for a couple reasons.
For one thing, it's undeniably a significant step forward for Web Platform as
a whole. For another, now people can struggle with the peculiarities of the
said Web Platform with their own languages. The legitimate grievances
associated with JS over the years were due to the browser APIs and first of
all DOM, which wasn't designed for JS to begin with and later just accumulated
problems for the sake of backwards compatibility.

~~~
RussianCow
I don't think that will be feasible in the near future, because in order to
run another language in the browser (say, Python) through wasm, you will need
to bundle the entire runtime with your app, which is an unacceptable amount of
overhead for most apps.

~~~
comex
I feel like this shouldn't be the end of the world. If everyone uses the same
CDN for a given language's runtime (with subresource-integrity to ensure
security), even a 1MB download should be... tolerable. Not great, but
tolerable. Load time is also an issue, but WebAssembly is designed to greatly
improve initial load time compared to asm.js.

~~~
Klathmon
That has been tried and failed with JavaScript libraries in the past.

Even if you can get everyone to agree on one canonical CDN (you can't), you
also need to get everyone to agree on one version of the file at the CDN.

Plus cache sizes on most platforms are laughably small (a heavy page can
completely blow out your cache on mobile devices).

IIRCthere was a "study" while back that found by using the most common CDN at
the time to host jQuery, you only got like a 5% cache hit rate. This was
because of multiple CDNs, multiple versions, multiple ways to reference the
version (1.2.3 vs 'latest'), and http/HTTPS.

In my past experience, we had more trouble with people blocking our CDN via
corporate networks or something.

~~~
douche
One of the problems with JS is the unbelievable amount of churn. It's not
uncommon to see libraries have version half-lives in the days or weeks.

The firewall issue is always going to be a problem on corporate networks. I
don't think we're ever realistically going to get away from having to self-
serve dependencies if you want to ensure that things are going to work,
particularly if it's software that is deployed in on-premise, internal
servers.

~~~
Klathmon
But this isn't a js churn problem. Even if updates only happen every 6 weeks,
that means that unless the majority of devs update their links every 6 weeks
the distribution of links out there will be spread out enough to be nearly
worthless.

And while updates every 6 weeks might seem crazy to you, unless we just don't
version the links (which seems like a terrible idea), even simple bugfxes blow
the whole system.

Plus CDN hosted systems come with a bunch of other downsides. Lack of http2
pushing, tree shaking and bundling doesn't work, being able to compile with
your own settings, and more.

CDNs aren't the solution here, something like using service worker and/or an
"install" process for web apps will solve all of these and more.

------
LeanderK
i feel like one important piece thats missing is a standardised debugging-API.
The introduction of WebAssembly will probably lead to a larger percentage of
people compiling a (completely different) language to something running in the
browser will rise. We need solid tooling for that.

~~~
kibwen
IIRC Firefox already implements the Chrome Debugging Protocol
([https://developer.chrome.com/devtools/docs/debugger-
protocol](https://developer.chrome.com/devtools/docs/debugger-protocol)),
which e.g. would mean that it should be possible to use Firefox's debug tools
to debug web pages in Chrome (and vice-versa). Would be nice to have some
clarification on this though.

EDIT: Some more clarification, apparently this is enabled by an official add-
on (called "Valence") which is shipped by default on Firefox Developer
Edition: [https://developer.mozilla.org/en-
US/docs/Tools/Valence](https://developer.mozilla.org/en-US/docs/Tools/Valence)

~~~
auchenberg
Firefox doesn't implement the Chrome Debugging Protocol, but has it's own
(FDP).

Valence is an protocol adapter that adapts CDP to FDP, so Firefox DevTools
(using FDP) can be used with iOS (which uses WDP)

------
dccoolgai
And so ended the Age of Javascript. Many will say, "good riddance" but I
wonder what we lose by making the Web less shareable and copyable...

~~~
labrador
From what I've read, the architects of WebAssembly are committed to still be
able to show source.

~~~
ilaksh
There will always be the S-expression format at least.

~~~
SquareWheel
The S-expression syntax will be temporary.

[https://www.youtube.com/watch?v=RByPdCN1RQ4&feature=youtu.be...](https://www.youtube.com/watch?v=RByPdCN1RQ4&feature=youtu.be&t=1714)

~~~
ilaksh
Replaced with what?

~~~
SquareWheel
Doesn't appear to be standardized yet, but some of the goals are outlined
here.

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

------
no1youknowz
Is there support for GoLang to WebAssembly?

Or will it be more of a GopherJS to WebAssembly?

Thanks

~~~
kibwen
The initial MVP of WASM won't have privileged support for any custom runtime
services, so in order to run Go code in the browser (or any other GC'd
language) you'd have to compile the entire runtime with it and ship it all
over the wire to the client. Eventually they do hope to lift this restriction.

~~~
hackcasual
The other issue is that a lot of GC implementations do stuff that's
incompatible with asm.js/WASM like inspecting function stacks.

~~~
couchand
Not entirely incompatible... an implementation could manage the stack
explicitly.

~~~
hackcasual
Not sure what you mean? Libraries like libgc can't be directly ported over to
Emscripten since they depend on platform specific behavior to inspect the
execution stack and registers.

In asm.js/WASM the execution stack is not inspectable from code.

~~~
couchand
Rather than using the execution stack provided by the environment (by using
the built-in calling conventions directly), you could manage your stack on the
heap using the linear memory facilities. Function calls are a bit more
expensive, since now you need a macro to convert calling conventions. But it's
definitely not impossible, and it's not even really all that hard (just
tedious).

------
msl09
>From that point forward, the binary format will be reset to version 1 and
WebAssembly will be versionless

Why?

~~~
CyberDildonics
The idea is that webasm won't have versions, it will have features that you
query, which is the way javascript and in fact actual assembly language works
today.

------
wvenable
Is there any sort of open source non-browser interpreter for Webassembly?

~~~
dubcanada
I don't know how useful that would be, it's still javascript (just a lower
level version of it) after all. It's coupled pretty tightly with the browser.

~~~
aspirin
WASM isn't related to JavaScript in any way. Maybe you were thinking of
asm.js?

You cannot access the browser APIs from WASM so there is no tight coupling
with the browser environment. I think non-browser use could make definately
sense.

~~~
0xdeadbeefbabe
> You cannot access the browser APIs from WASM

Do you have a reference? I'm confused about why you wouldn't want to access
browser APIs.

~~~
smitherfield
Right now it's more like Flash or Java applets, running in a sandbox within a
sandbox.

~~~
TazeTSchnitzel
Huh? WebAssembly, like asm.js before it, can access Web APIs (albeit via JS).

~~~
hackcasual
Not exactly. You have to export those APIs into the WebAssembly module. It's
certainly possible to have a WASM implementation that doesn't provide web
APIs, but is still WASM.

------
crudbug
Is there a plan to support WASM in NodeJS anytime soon ? I see multiple
optimization points on the server side as well.

~~~
nkassis
I might be missing what you are trying to do but can't you get that
optimization today with using FFI to use native modules in your server side
code?

~~~
s3th
The main benefit would be shipping a single WebAssembly module to target
client and server (e.g. the same benefit of sharing JS between the browser and
Node).

------
votr
Is there support for only C/C++ at this time?

~~~
bobajeff
Yes. WebAssembly like asm.js is intended for porting C/C++ apps to the web.

That said compiled languages should work if compilers add support for
generating WebAssembly.

~~~
vmarsy
Yes, for instance Swift should be able to compile to web assembly? If Swift
can be compiled with the clang/llvm toolchain, it should be able to target web
assembly.

------
reitzensteinm
Anyone know what the best way to compile and run the text format in the
browser is?

I'm working on a compiler for Clojure, which also runs in cljs, and would love
to attempt to make a back end for it that runs in the browser.

~~~
azakai
If you want to compile the code as-is, then wabt is the most straightforward
tool for that (specifically wast2wasm).

If you want to also optimize the code, then binaryen can do both (wasm-opt to
optimize, wasm-as to convert to binary).

Since this is for a compiler backend, then the optimizations are probably
relevant for you.

~~~
reitzensteinm
Sorry, I wasn't clear, I mean run the entire thing in the browser, to make it
interactive. Since Chrome apparently supports the text format as a way to view
the binary, I was hoping that it would support a two way process.

However, from searching around, it looks like I'll have to emit bytecode
directly, at least for the near future. Which isn't the end of the world I
guess!

~~~
azakai
Oh I see, sorry for misunderstanding.

Yeah, I think it would have been nice to have text format input support in
browsers, but the decision was against that.

But you do have other options than emitting binary wasm yourself. You can use
a compiled version of wabt or binaryen, here's an example of binaryen.js,

[https://github.com/WebAssembly/binaryen/blob/master/test/bin...](https://github.com/WebAssembly/binaryen/blob/master/test/binaryen.js/test.js)

edit: actually it looks like the test doesn't cover WasmBinaryWriter, which is
what would be needed for this, we should improve that

~~~
binji
Here's the emscripten-compiled wast2wasm (from wabt):
[https://cdn.rawgit.com/WebAssembly/wabt/2baa1ecb0b36bea6268c...](https://cdn.rawgit.com/WebAssembly/wabt/2baa1ecb0b36bea6268c52ea49246aafbed05f02/demo/index.html)

It uses the code from here:
[https://github.com/WebAssembly/wabt/tree/master/demo](https://github.com/WebAssembly/wabt/tree/master/demo)

------
BatFastard
Does anyone know what approach they have taken to access the GPU? I saw some
discussion last year, but nothing clear.

~~~
irq-1
Looks like the plan is to expand the JS access to WebGL.

[http://webassembly.org/docs/gc/#webidl-
integration](http://webassembly.org/docs/gc/#webidl-integration)

~~~
BatFastard
So this is still in the planning stage. Sounds like it is a major part of what
they want to deliver, hope it doesn't take TOO long.

------
TheAceOfHearts
Maybe someone that's more familiar with wasm can enlighten me, but isn't this
still extremely limited in the capabilities it exposes? With so many
limitations in place, what are some example use-cases that this helps with? Am
I being too negative and unrealistic? I don't know what kind of expectations I
should have. I'm not writing this to bait responses.

It seems to be that until you get lower level network capabilities and some
form of file system access, you're just too limited.

~~~
dpacmittal
>It seems to be that until you get lower level network capabilities and some
form of file system access, you're just too limited.

JS doesn't give you those things either but would you call it limited?

I think its a very early preview and we can expect a lot of limitations
removed as the technology progresses.

~~~
TheAceOfHearts
I do think JS is very limited for non-networked applications. If most of what
you're doing is hitting APIs and displaying that data, it's great.

But if you're building an app that doesn't depend on the network, you find
yourself way more limited in most cases. The solution for many people is to go
for Electron, but that takes you completely out of the web sandbox.

I understand that it's incredibly challenging to get multiple vendors to agree
on anything, and I'm sure we'll get to a good place eventually, but I guess
I'm just feeling a bit frustrated with the state of things.

What does this initial release of wasm enable? I've heard that game developers
are expected to be the initial target audience. Do we provide adequate APIs
for storing game assets? As an example, I think the latest Doom game is 50GB.

I guess I'm a bit concerned that all of this incredible work will get done and
released, but nobody will be able to make use of it? Is this a legitimate
concern or am I being irrational? I guess I'd have a bit more peace of mind if
there were some examples of concrete use-cases that are expected to be solved
by this work. Maybe these use-case examples already exist and I haven't seen
em? I'll admit I haven't looked around much.

This is a concern I've had with regular web APIs as well. Sometimes I'll read
about a new spec that's being developed, but maybe due to my poor
understanding or lack of knowledge, I'll end up confused as to the purpose of
those APIs.

------
chx
We have been watching people redoing computer software perhaps 20 years behind
with JS (the original Doom was ported in 2011, if I remember correctly, please
bikeshed the exact number of years) Let's hope WebAssembly will seriously cut
this figure down.

------
TbobbyZ
Based on this tutorial

[http://webassembly.org/getting-started/developers-
guide/](http://webassembly.org/getting-started/developers-guide/)

web assembly lets youvwrite web apps in C?

------
Ericson2314
I you think about it, a WASM "process" is a great middle ground between a
conventional VM (ugly hardware skeoumorphism) and container (ugly Unix).

I hope this becomes the standard interface for server hosting, not just the
browser.

------
wentoodeep
Finally, time to create a programming language that run on top of wasm.

~~~
nippur72
[https://github.com/evanw/thinscript](https://github.com/evanw/thinscript)

------
mschuetz
What about debugging? A useful debugging suite, like the current chrome
developer tools for javascript, is a must have in my opinion.

------
partycoder
This is great. I cannot wait for projects like Scala.js to compile to
WebAssembly, to bring some more language diversity to the browser.

------
iamleppert
Bye bye, native app developers...

~~~
SadWebDeveloper
Unless you own an iPhone/iPad like half the kids in the world today.

~~~
equasar
Webkit won't support it?

------
grondilu
How reasonable is it to hope that WebAssembly becomes a compilation target for
GCC?

------
z3t4
My biggest worry is that everyone will turn this off due to security concerns.

------
hitlin37
so it compiles c++ to webassembly syntax using empscripten compiler. what js
has to do with webassembly? Is the idea is same with js? i.e. compiler js code
to webassembly.

 _noob here on web assembly._

------
nickthemagicman
SO EXCITED!! Cant wait to get a block scoped language in the browser!!

~~~
atrilumen
You mean like JavaScript?

[http://caniuse.com/#search=const](http://caniuse.com/#search=const)

[http://caniuse.com/#search=let](http://caniuse.com/#search=let)

~~~
nickthemagicman
No I mean a REAL block scoped language! JS is cool but these are just bolted
on features.

Why does a function I pass into an Ajax query need a call statement?

Why does 'this' have so many interpretations depending on its context?

Other languages approach these in simpler ways. Functions inherit the scope in
which they are executed and 'this' applies to its parent object.

Also, whats up with nested asynchronous statements?

I know ES6 and 7 are working on it but new languages would be ideal with new
takes on solving some of the tough parts of web development.

------
mring33621
Everybody hated Java applets. Terrible for security! Worst thing ever! Glad
they're gone!

Hmmmmmm...

~~~
wmil
Java applets needed to interact with the OS in various ways and required
browsers to have sub views controlled by plugins. They were a lot more complex
and risk prone. Especially since Sun kept adding features.

WASM is much simpler. It's just a standard bytecode format that the JS engine
can handle. It's much easier to secure.

~~~
hackcasual
WASM feels like an evolution built on top of a lot of what's worked with
Javascript.

------
jlebrech
will this mean we can use gtk for websites in the future?

~~~
imtringued
You can run Qt in the browser already.

[http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...](http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-
qt/wiki/Demos)

I wouldn't recommend it.

~~~
jlebrech
yep, i'm looking for a library that's in a state that you WOULD recommend it.
:)

------
awqrre
Being a binary format is the worst part of WebAssembly... for the open web.

~~~
haberman
There is this weird belief that being a text format automatically means open,
reusable, interoperable and being a binary format automatically means closed,
proprietary, opaque.

As counterexamples, here are several binary formats that are very open: ELF,
DWARF, PNG, tar, gzip, Ogg and all its subformats, FLAC, JPEG2000.

On the other hand, you have something like OOXML, which while technically
open/standardized, is so incredibly complicated that it is extremely difficult
to implement well. Just because something is text-based does not make it
simple.

~~~
z3t4
I think Wasm will be more advanced then PNG. And if there are code execution
exploits in PNG, I can only imagine how many exploits there will be in Wasm.

~~~
haberman
And how many have there been in HTML, JavaScript, and CSS?
[https://en.wikipedia.org/wiki/Pwn2Own](https://en.wikipedia.org/wiki/Pwn2Own)

------
tmzt
I guess this explains some things I heard last week ;)

