Compiling JavaScript text source code into a binary representation of its AST will save time and space downloading, and time starting up.
You won't need another JIT compiler, the web browser usually already has one. WebAssembly is bytecode and JIT agnostic. Compiling text JavaScript into a binary WebAssembly representation of the parse tree is different than compiling the parse tree to bytecode, or JITting the parse tree or bytecode to machine code. They are complementary layers, and both synergistically useful together.
[1] http://bytecrafter.blogspot.nl/2015/06/a-quick-overview-of-w...
This compiled/interpreted distinction has gotten quite fuzzy, and it has been for decades now. Smalltalk was always a compiled language with really late binding. It did compile to a bytecode which was interpreted at first, but that became JIT compiled in all but one commercial VM. This all happened over a decade ago.
Also, there is clearly a subset of Javascript programs that could be usefully compiled down to a small, fast, compact machine language program.
I suppose the extra restrictions of Typescript would help. At least if you add extra restrictions to make it easier to compile.
These are totally sensible. Look at: http://www.call-cc.org/
...which will also make it feasible to use other gc:ed languages without shipping an enormous runtime.
I'm not sure how much space just cutting out the GC will save?
I mean, it is if you compile it to wasm. It is definitely JIT compiled.
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 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.
https://github.com/WebAssembly/design/blob/master/FAQ.md#whi...
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/...
No one wants to do web development in C++ honestly, but they would like the performance.
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.
A javascript application compiled to wasm doesn't really make sense. Javascript isn't a compiled language. The best you could do would be to store some kind of compressed representation of the source code, along with a JIT compiler to run that source code. It isn't a sensible thing to do.