Then you have to ship your own GC with it.

I think you misunderstand what WebAssembly is about.

As I understand it, it's little more than a binary serialization of JavaScript ASTs. In which case, no, you don't need to ship your own GC with it.

I mean, you could always write a JavaScript interpreter in JavaScript, and then compile that into WASM, in which case, yes, you'd ship your own GC. I don't see why you would feel the need to do that for real world applications, though.

> I think you misunderstand what WebAssembly is about.

I don't, WebAssembly is about C++, primarily. Every design decision has been to support C++. Everything else is an afterthought that will come later. WebAssembly isn't about minifying your JS.

Read this: https://github.com/WebAssembly/design/blob/master/GC.md GC, DOM access, etc. don't exist in WebAssembly code, yet.

It's C++ first as a convenience, since LLVM is best at C++ and emscripten w/asm is a solid benchmark. It is NOT primarily about C++ just because that's the v1.

https://github.com/WebAssembly/design/blob/master/FAQ.md#whi...

It's not about C++ primarily, it's about building on the base which asm.js laid out. C++ would only feature in this because of Emscripten.

WebAssembly is a compact serialization of asm.js, not of arbitrary Javascript.

That's true of version 1, but supporting arbitrary JavaScript is on the roadmap (step 3, "everything else" [1]). Which will be awesome!

What I'd love to be able to do with tools like Unity3D that compile C# and other CLR languages into asm.js, would be to pass JavaScript objects directly in and out of the C# code so you can manipulate the underlying JavaScript objects directly from C# with little or no overhead.

Right now of course you can implement JSON libraries in C#, but it's indirectly and inefficiently layered on top of the flat memory model of asm.js. I want to be able to use the native JavaScript objects and libraries directly from other languages like C# that compile into JavaScript. That would be ideal!

To do that, asm.js would need a way to store references to garbage collected JS objects somewhere, somehow, using proxies or handles represented in linear memory, opaque reference types [2], or some other magic like that, like Apple's JavaScript/Objective C bridging stuff [3].

[1] http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-w...

[2] https://github.com/WebAssembly/design/blob/master/GC.md

[3] https://developer.apple.com/library/mac/documentation/Cocoa/...

Interesting. But then it wouldn't really be compilation, but parsing + serialization. I guess the distinction is rather pointless.

This conversation was confusing until I read this point

My initial reaction was for software with a flat memory footprint, so it really doesn't require garbage collection. Our application could be written in C, if we weren't web developers who are working in JavaScript.

No one wants to do web development in C++ honestly, but they would like the performance.

I could see this functioning really well with webworker once some sort of thread-safe representation is in place for quickly moving objects in/out of said worker... Would be a pretty clean separation of WebAssembly code, and the DOM accessible code by convention... even if sticking to object serialization (JSON), it would be pretty clean...

With IE9 support slipping, it seems to be a no-brainer in terms of support at this point too [1].

I'm also thinking this could be a huge win once it hits node.js (v6?), as this could be a great answer to better binary module support. As binary modules are a bit of a pain to support, and prebuilt binary modules are in a hodge-podge state.

[1] http://caniuse.com/#feat=webworkers