Hacker News Reader

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

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

How is crawling WebAssembly any slower than crawling JavaScript?