| > I feel this point is slowly becoming disingenuous. If someone goes through the trouble of compiling their application to asm.js, they obviously really care about performance, because "normal" javascript wasn't good enough for them. ...what? asm.js is a compiler target for C code. It's not intended to be hand-written. It's also the default compiler target for C code on the web. You wouldn't really want to compile to anything else, except NaCl I suppose (though that requires more porting effort). I don't get what you mean by "going through the trouble of compiling their application to asm.js" versus ""normal" javascript wasn't good enough for them.". Why would they compile to normal JS? There's no reason to: Their codebase is in C, C++, or some other native code language. If they compile to asm.js, they get a free performance boost. If they compile to JS, they just get horrible slowness. The only difference between them, here, is a single compiler flag. I don't understand. > Hell, elm/cljs/scala.js/js_of_ocaml/etc wasn't good enough. How many asm.js developers do you know that will go through the trouble of compiling a codebase to asm.js, without putting up an alert('This app works best on Firefox');? Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists? > Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js. > I'm a huge Mozilla fanboy, but I feel like they bit off more than they could chew here, and I think the effort would be better spent on standardizing a spec for a true VM instead of trying to back-compat-hack one into javascript. It's not a VM, there's no JIT involved. |
> Why would normal JS developers be writing in asm.js? Do you even understand why asm.js exists?
Normal JS developers would use asm.js if they needed extra performance. I occasionally need extra performance out of javascript, so I use heavily optimized clojurescript, which helps for some applications. If I had exhausted those options, I would try programming in C and compiling to asm.js.
> What barriers to entry? You download the emscripten SDK and you compile your existing C/C++ app to asm.js.
Ha. You obviously haven't tried to do that yet. asm.js is intended to be a compiler target for many languages. It only succeeds for two languages (C/C++), thanks to emscriptem more than asm.js, and even that is not trivial. It takes significant effort to port most C/C++ applications...otherwise they wouldn't have their own codebases, they would just be a different target on a makefile. If it were as simple as you make it out to be, we would have hundreds of languages compiling to asm.js by now; C/C++, but also every language that compiles to C/C++ or LLVM bytecode. As it is, we have maybe a couple dozen large legacy codebases that have been ported.
> It's not a VM, there's no JIT involved.
A VM does not necessarily imply JIT, but that is beside the point. A VM executes bytecode, and asm.js is an attempt to use javascript as bytecode. Javascript wasn't designed as a VM, and several of its "features" actively subvert its use as a VM, which is why asm.js relies on guarantees that you will not use those features.
If getting the performance that asm.js developers expect out of asm.js requires the use of a browser that optimizes for asm.js, then the solution isn't cross-platform. In fact, it isn't really any better than NaCL, god forbid.