I don't know, you have a real mix of arguments here, as do most people. There's nothing a JIT does that an ahead of time compiler can't do without the burden of a larger footprint.
This is really an issue of backend optimization to "make things like asm.js."
For example, there are obvious examples of cases where a JavaScript object's properties and property types would be transparent to a compiler at compile time, with a complete graph of where those values would be stored and used. This would be stored in the WebAssembly stack, analogous to an asm.js fixed array.
The WebAssembly sandbox is designed to run code directly. The JIT is designed to build code to run directly in an iterative fashion. If system designers knows how software is expected to operate, they can make choices to instrument that process and also make software which is designed intelligently.
Java runs in a VM. Someone could write a just in time compiler for .java code that performs well. That's not a sufficient argument not to develop or continue to develop a javac compiler for byte code. Additionally, whether or not a language is designed to use GC doesn't mean there couldn't be research or design into avoiding or augmenting that situation for performance (in the way that a just-in-time compiler would relieve the situation). Nor reason not to build a platform and engineering methodology to deploy to two independent and cooperating runtime environments.
Neither Asm.js and emscripten or C are the end of all things. Neither is dynamicism.
This is really an issue of backend optimization to "make things like asm.js."
For example, there are obvious examples of cases where a JavaScript object's properties and property types would be transparent to a compiler at compile time, with a complete graph of where those values would be stored and used. This would be stored in the WebAssembly stack, analogous to an asm.js fixed array.
The WebAssembly sandbox is designed to run code directly. The JIT is designed to build code to run directly in an iterative fashion. If system designers knows how software is expected to operate, they can make choices to instrument that process and also make software which is designed intelligently.
Java runs in a VM. Someone could write a just in time compiler for .java code that performs well. That's not a sufficient argument not to develop or continue to develop a javac compiler for byte code. Additionally, whether or not a language is designed to use GC doesn't mean there couldn't be research or design into avoiding or augmenting that situation for performance (in the way that a just-in-time compiler would relieve the situation). Nor reason not to build a platform and engineering methodology to deploy to two independent and cooperating runtime environments.
Neither Asm.js and emscripten or C are the end of all things. Neither is dynamicism.