3 ms·

Compiling from JavaScript to WebAssembly is not possible and makes no sense. https://github.com/WebAssembly/design/issues/219 https://github.com/WebAssembly/de

• frik 11y ago
  Bla bla wrong. Mozilla OdinMonkey is used for asm.js, it's a seperate engine in Firefox (https://en.wikipedia.org/wiki/SpiderMonkey https://en.wikipedia.org/wiki/SpiderMonkey ). The general purpose JS engine is SpiderMonkey (TraceMonkey, JägerMonkey). So, Firefox already excutes asm.js faster than general purpose JavaScript due to an different faster implementation. And you can easily imagine that other vendors will follow them with WebAssembly. Then the only way to get that extra speedup bonus is to compile Javascript to WebAssembly. Well, let's hope Google realises that crawling web apps based on WebAssembly will consume a lot of CPU cycles and will decrease their rank or not index them at all. This will put an damper so that WebAssembly is only used for SaaS web apps compiled from native C++ and not for the vast amount of general purpose websites as a CEO technique to speed up the page load - which would be a real trojan horse, and dangerous for the web. Maybe I should add "patent pending", so that Microsoft, Adobe et all won't cripple the web.
  • hun-nemethpeter 11y ago
    I linked the official webassembly design page where the authors said compiling from JavaScript to WASM is not possible now. "jfbastien commented on Jun 24, 2015 JS → wasm will only really make sense once wasm supports GC, and most likely JIT compilation too, which is still quite a while away. This would basically be equivalent to implementing the JS engine in wasm! I mentioned this recently and @BrendanEich accused me of having been taken over by horse_js. To be clear, wasm's goal isn't to replace JavaScript, it's to supplement it. It's therefore not really a goal at the moment to support JS → wasm, but the features we want to implement will make it possible. I'm not sure it'll be that useful from a developer's perspective, though. You may get some size reduction, but that's about it. From a browser's perspective it may be interesting to have the JS engine implemented in wasm from a pure security perspective."
  • pcwalton 11y ago
    > Well, let's hope Google realises that crawling web apps based on WebAssembly will consume a lot of CPU cycles and will decrease their rank or not index them at all. This will put an damper so that WebAssembly is only used for SaaS web apps compiled from native C++ and not for the vast amount of general purpose websites as a CEO technique to speed up the page load - which would be a real trojan horse, and dangerous for the web. Google will never do this. There's no indication whatsoever that Google (or for that matter any other browser vendor) is opposed to delivering apps over the Web in compiled format. Remember Google Web Toolkit? Closure Compiler? If you want to argue against wasm on the grounds that it makes reverse engineering harder, then you should also be opposed to JavaScript transpilers and source minifiers. That's an intellectually coherent position to take. However, no browser vendor to date has taken this position, and to suggest otherwise is just narrative constructing.
  • cpeterso 11y ago
    How is crawling WebAssembly any slower than crawling JavaScript?