4 ms·

> It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser su

> It is just JavaScript, so any browser can execute asm.js code, but it can be AOT compiled by some browsers for extra performance - This means every browser supports asm.js, and supports it today 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. 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');? Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. 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.

TazeTSchnitzel 12y ago
> 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.
- saosebastiao 12y ago
  If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up). > 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.
  - TazeTSchnitzel 12y ago
    > If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up). I'm not sure that's really true. It doesn't have to be ultra-fast, just good enough. > 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. Er, well, there aren't many languages which compile to native code. People can't compile Java, C#, JavaScript, Perl, Python, Ruby, PHP, etc. to native code. C/C++ do compile to native code, however. > Ha. You obviously haven't tried to do that yet. Oh, I have. I realise it has some difficulty to it. > 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. I'm not sure what you think asm.js is the solution to. Its purpose is for running native applications in the browser. It's not for making ordinary JS apps run fast.
beagle3 12y ago
You seem to have your concepts mixed. asm.js is a compiler that produces portable standard JavaScript output, like CoffeeScript or Elm or ClojureScript, except that its source language is C or C++. The output works on any browser supporting JavaScript, including Chrome and IE. It works very well on Chrome and Mozilla (haven't tried IE recently - old IEs would be slow due to missing TypedArrays and friends, but it would still work). Yes, the created JavaScript is annotated in a way that Mozilla uses to improve speed (and other browsers can, though they do not yet as far as I know) - but those annotations are still perfectly standard JavaScript that even the oldest IE is not confused by. The main use that I'm familiar with for asm.js is to make use of an existing C/C++ codebase. See e.g. all of https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos https://github.com/kripken/emscripten/wiki/Porting-Examples-... and especially the utilities section. Rewriting Poppler, GnuPlot, eSpeak or SQLite in JavaScript is no small undertaking - and asm.js makes this rewrite unneeded. > Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. While using the asm.js toolchain may not be trivial (or it may be - I last tried it a long, long time ago), it is only the outputs that are meaningful for end users, and those outputs are already compatible with every other browser. The assertion about a Mozilla only ecosystem makes absolutely no sense. > 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. Those who ignore history are doomed to repeat it. This idea has been aired in some way or another since the early 60s. And yet, every single implementation has failed to deliver on the goals of a "one true VM" (yes, including the CLR, JVM, UCSD p-Code, and tens of other that did gain some traction). The best "true VM" we have today is, surprisingly, x86 and AMD64 bytecode. It has a hardware implementation, which makes it wicked fast compared to all the others - and it is also significantly lower level than any "true VM" proposed to date. Luckily, Mozilla is learning from history and not ignoring it.

TazeTSchnitzel 12y ago

> 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.

saosebastiao 12y ago
If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up). > 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.
- TazeTSchnitzel 12y ago
  > If Opera/Dolphin/Safari/whatever don't ever implement optimizations for asm.js, its not really cross-platform anymore. Sure, theoretically they can execute the code, but the performance will be so far from the expectations of the developer that they will just end up telling the user to switch to Firefox (maybe Chrome if they can ever catch up). I'm not sure that's really true. It doesn't have to be ultra-fast, just good enough. > 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. Er, well, there aren't many languages which compile to native code. People can't compile Java, C#, JavaScript, Perl, Python, Ruby, PHP, etc. to native code. C/C++ do compile to native code, however. > Ha. You obviously haven't tried to do that yet. Oh, I have. I realise it has some difficulty to it. > 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. I'm not sure what you think asm.js is the solution to. Its purpose is for running native applications in the browser. It's not for making ordinary JS apps run fast.

beagle3 12y ago

You seem to have your concepts mixed. asm.js is a compiler that produces portable standard JavaScript output, like CoffeeScript or Elm or ClojureScript, except that its source language is C or C++. The output works on any browser supporting JavaScript, including Chrome and IE. It works very well on Chrome and Mozilla (haven't tried IE recently - old IEs would be slow due to missing TypedArrays and friends, but it would still work). Yes, the created JavaScript is annotated in a way that Mozilla uses to improve speed (and other browsers can, though they do not yet as far as I know) - but those annotations are still perfectly standard JavaScript that even the oldest IE is not confused by. The main use that I'm familiar with for asm.js is to make use of an existing C/C++ codebase. See e.g. all of https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos https://github.com/kripken/emscripten/wiki/Porting-Examples-... and especially the utilities section. Rewriting Poppler, GnuPlot, eSpeak or SQLite in JavaScript is no small undertaking - and asm.js makes this rewrite unneeded. > Unless the barriers to entry for compiling to asm.js can be very significantly reduced, it will become a Mozilla-only ecosystem. While using the asm.js toolchain may not be trivial (or it may be - I last tried it a long, long time ago), it is only the outputs that are meaningful for end users, and those outputs are already compatible with every other browser. The assertion about a Mozilla only ecosystem makes absolutely no sense. > 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. Those who ignore history are doomed to repeat it. This idea has been aired in some way or another since the early 60s. And yet, every single implementation has failed to deliver on the goals of a "one true VM" (yes, including the CLR, JVM, UCSD p-Code, and tens of other that did gain some traction). The best "true VM" we have today is, surprisingly, x86 and AMD64 bytecode. It has a hardware implementation, which makes it wicked fast compared to all the others - and it is also significantly lower level than any "true VM" proposed to date. Luckily, Mozilla is learning from history and not ignoring it.