[flohofwoe]

You shouldn't have to deal with C++ directly unless you really want to, it's more likely that there will be 'precompiled' WebAssembly modules of existing C/C++ libs which solve computation-heavy tasks (like physics engines, image manipulation, 3d rendering frameworks etc)... and which would offer a Javascript API. The workflow for JS devs would be the same as using a minified Javascript framework now, but instead of a minimifed JS blob you'll load a WebAssembly blob.

[CryZe]

Without finalizers in JavaScript, WASM Libraries don't work out well, as you need to do manual memory management in your JavaScript code then, as you won't be able to hook the native destructors into the Garbage Collector of JavaScript. So until those are a thing, it'll be extremely ugly to work with WASM Libraries in JavaScript.

[flohofwoe]

I think emscripten does this by keeping dictionaries on the Javascript side which map numeric "ids" (used on the asm.js/wasm side) to JS objects. This is how mapping a GLuint 'texture id' to WebGL objects works for instance. The JS object won't be garbage collected as long as it 'pinned' in the lookup dictionary, but as soon as the asm.js/wasm side manually release the handle, the JS object will be GC'd. Future APIs (like the a WebGL successor) will hopefully provide 'garbage free' APIs so that they don't require keeping such helper structures around.