Experimental support for WebAssembly in V8

Re:Experimental support for WebAssembly in V8 by RussianCow on Tuesday March 15, 2016 @01:57PM (#11291619)

But the point is, if you want to compile your JavaScript code ahead of time, you have to ship your own GC and JIT compiler, because you no longer get it "for free" from the browser's JS implementation. There's absolutely no benefit from doing this.

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by geon on Tuesday March 15, 2016 @03:37PM (#11292375)

That will soon not be true. Exposing the js gc is on the roadmap.

...which will also make it feasible to use other gc:ed languages without shipping an enormous runtime.

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by RussianCow on Tuesday March 15, 2016 @05:01PM (#11292961)

Okay, but why would you compile JS down to wasm, only to have it then use the browser's built-in JS runtime? I see the use for compiling other dynamic languages, but compiling JS via wasm shouldn't be any different than running it via the normal JS engine, aside from potentially having a slightly smaller executable.

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by tanlermin on Tuesday March 15, 2016 @03:56PM (#11292498)

But they will still need to be interpreted ie cpython.

I'm not sure how much space just cutting out the GC will save?

[ Parent | on HN ]

Re:Experimental support for WebAssembly in V8 by esailija on Tuesday March 15, 2016 @04:20PM (#11292655)

GC is only a small part of a high level language runtime.

[ Parent | on HN ]