"The initial implementation of WebAssembly support in browsers will be based on asm.js and PNaCl". PNaCl? https://en.wikipedia.org/wiki/WebAssembly , https://en.wikipedia.org/wiki/Asm.js

So is WebAssembly mere an asm.js v2 where all browser vendors agreed on a standard?

WebAssembly should give us opportunity for this.

If I can use C/C++ with static typing(of course if I can do DOM manipulation from my C/C++ program) why I should use JS?

You might not like JS personally but there are plenty of things to like about it and many other people do.

In practical terms, browsers will support JS forever for backwards compatibility even if all new code is written in WASM.

The relationship between WASM and JS seems to be "js/js virtual machines are a de facto standard, so let's not repeat the mistakes of Java plugins and instead build off that foot-in-the-door."

You could make the same argument about any higher level language, even those with as many quirks as JS, like PHP ;)

This is cool, because this means people will implement their own garbage collection mechanism, which could lead to interesting innovations.

Modern computers getting slow at 20 tabs of typical news sites articles is already pretty interesting. But I can't wait to see how can we innovate this even further!

I'm impressed you can read 20 articles at once! (Said only half jokingly. I do the same thing, but optimizing my behavior is probably the better solution to slowness)

2. If web-assembly incorporates a GC, then it will become needlessly complicated.

3. Unnecessary complication in web-assembly means also unnecessary room for security flaws.

(4. What good is a web assembly if you can't implement an efficient garbage collector in it?)

1 - https://github.com/WebAssembly/design/issues/104

What is wrong with open-sourcing GC code as independent libraries, so that web-app makers or (more likely) compiler developers (with less skill/time) can use them at will?

> the issue with #4 is that you would need threads w/ shared memory

But this is exactly what we need for other applications as well. For example, how would you send a large immutable data-structure across two threads? By copying it? Of course not, you just share pointers, meaning that the address space should be shared. If this is not possible, then that is a major flaw in WASM's design.

I think you have the impression that incorporating a GC into WASM makes life easier. But it doesn't. It is the exact opposite. WASM should be as simple as possible.

I don't think it is. What I would like to see is that compiler writers keep control over their GC.

> Waiting until WASM has the ability to do threaded memory management at the same level as the existing GCs and have them rewritten (or refactored) for it may be too long.

I don't see the big problems. We already have assembly without GCs, and it is called VirtualBox (or VMWare). Why not use something like that? (Yes, there are still some security issues, but these can be solved much easier than when the hairy GC code becomes part of the game).

In other words, let's first create a real assembly language with a simple but adequate instruction set, and make it secure. This is what I would call "assembly language" anyway.

There's nothing that would prevent writing your own GC if you felt the need.

Since WebAsm is still Functional languages would still have the freedom to implement their own more efficient GC (avoid the write barrier in a lot of cases, scan only the young heap most of the time, etc).

This sounds a lot like "640k ought to be enough for everyone" :)

Also, it only addressed my first point.

There's nothing stopping you from implementing your own GC. But having a standardized GC (the JS engine's GC) means much simpler interop between wasm languages.

Heh, since every binary executable has a non-compiled source code somewhere out there, can we call them readable too?

Think of it like how assembly is to machine code, but probably more readable.

In my experience, carefully optimized JavaScript is still 10x slower than equivalent C++. C++ to JS brings that down to 2x.

WebAssemly will have a readable text format for view-source functionality: https://github.com/WebAssembly/design/blob/master/TextFormat...

Second:

"...so much easier to spy on people and hide all kinds of nastiness in web applications."

What kind of spying and nastiness? WebAssembly will not have more access to your data than the JavaScript API. It will have access to the same API as JavaScript. For example if it wants your location it will call the same HTML5 location API and with the same restrictions, with the permission popup. Or setting cookies will also call the same API. And thanks to the built-in developer tools in browsers you can check the outgoing requests to see what is sent and to where.

It's not so much about spying on your computer and gaining extra access, it's obvious (short of implementation bugs) that you won't gain any additional privileges that way.

But what you will gain is a way to obfuscate extremely well "report such and such to some webserver" in a way that's difficult to detect. For example, you can hide the entropy inside of a fairly innocent looking URL and without a lot of digging you won't know what that entropy represents. It can look like just a plain jane resource request and the webserver can serve up the exact same resource no matter what the entropy is, but also record that entropy for a back-channel way of exfiltrating information from your browser.

Finally, it opens up a whole new world of compiler attack. Right now the attacks against wordpress involve writing some information into a file and making it look "weird but I don't know what it does so I'd better not touch it".

What happens when breaking into a wordpress install means that you can execute the equivalent of the untraceable compiler login exploit insertion attack? You can't perform this attack without 1) a compiler and 2) a low level target that's hard to understand. You don't even need to perform a stage 3 attack which is the most sophisticated, a stage 2 would do fine.

https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...

I don't think this is going to be an issue, or be any different than where we are now.

That's definitely not true. Minified JS is everywhere.

Read C source. Then go read the machine code that C compiles into. I assure you that the C is far, far more readable even if you've HEAVILY obfuscated it.

In order to better understand this, I present you with a StackOverflow answer: http://stackoverflow.com/a/331474

This:

int get_int(int c);

int main(void) {

    int a = 1, b = 2;

    return getCode(a) + b;

Might yield this:

00000000 <main>:

int get_int(int c);

int main(void) { /* here, the prologue creates the frame for main /

   0:   8d 4c 24 04             lea    0x4(%esp),%ecx

   4:   83 e4 f0                and    $0xfffffff0,%esp

   7:   ff 71 fc                pushl  -0x4(%ecx)

   a:   55                      push   %ebp

   b:   89 e5                   mov    %esp,%ebp

   d:   51                      push   %ecx

   e:   83 ec 14                sub    $0x14,%esp

    int a = 1, b = 2; /* setting up space for locals */

  11:   c7 45 f4 01 00 00 00    movl   $0x1,-0xc(%ebp)

  18:   c7 45 f8 02 00 00 00    movl   $0x2,-0x8(%ebp)

    return getCode(a) + b;

  1f:   8b 45 f4                mov    -0xc(%ebp),%eax

  22:   89 04 24                mov    %eax,(%esp)

  25:   e8 fc ff ff ff          call   26 <main+0x26>

  2a:   03 45 f8                add    -0x8(%ebp),%eax

  30:   59                      pop    %ecx

  31:   5d                      pop    %ebp

  32:   8d 61 fc                lea    -0x4(%ecx),%esp

  35:   c3                      ret

Go look at the spec. It's at a much lower level of abstraction than JavaScript is. https://github.com/WebAssembly/design/blob/master/AstSemanti...