2. I have bad news for you. Open any web-site (e.g. "google.com") and try to view its source. Is minified JS really that readable?
[1]: https://github.com/WebAssembly/design/blob/master/FAQ.md#wil...
That was not my experience when I ported a large C app over to asm/emscripten. The mapping from C was very transparent. I had no problem using the dev inspector to debug the code.
Also, I hate the "transpiling" verb and your usage of it is incorrect. We started using "to transpile" as a way to inform people that some compilers, such as CoffeeScript, have a Javascript output that's still readable and that doesn't lose abstraction in the process, the "transpiler" being defined as a "source to source compiler". People preferred this term to convey the information that some languages like CoffeeScript are just mere syntactic sugar over Javascript.
On one hand that's superfluous when the very definition of a "compiler" is that of a program that transforms source code from one programming language to another. And on the other hand, people are using it incorrectly. The minified output of something like Google's Closure compiler, coupled with the higher-level abstractions in languages like ClojureScript or Scala.js, etc, leads to a Javascript output that is no longer readable and that does lose abstraction in the process.
Isn't that possible with many languages since the compiled code snippets are obvious.
I've always thought transpiling was defined as compiling from one language to another language that is at the same abstraction level. Usually compiling goes from a high abstract level to lower.
Personally I think that's a silly redefinition of compilation. We should just use "to compile" / "compiler" and be done with it.
Look at WebGL. There's a site which lists the best WebGL sites.[1] Most of them are demos. Some which aren't:
- http://breakthrough.nationalgeographic.com -- a menu system which puts you inside a sphere. Somebody really liked Lawnmower Man.
- http://histography.io -- a timeline of history. Only works on Chrome or Safari.
- https://www.rudys.paris/ -- a shoe store. Doesn't seem to have any 3D; they just seem to be using WebGL for zooming. Takes forever to load, and they broke the Back button.
- http://www.thehappyforecast.com/ -- an interactive "happiness map" of London. But it's just an overly fancy 3D menu.
- http://www.webglgames.com/ -- Deadtrigger 2 (zombies), They Will Eat You (more zombies), X-Wing (the 80s called, they want their arcade game back.)
You could do most of this stuff in Flash, and it would load much faster. Browsers now have more technology than use cases.
[1] http://cssnectar.com/css-gallery/nominees/site-features/webg...
All else being equal, would you rather have a .swf binary blob that depends on Adobe, or a WebAssembly binary blob that follows a well defined internet spec and independent implementation by multiple authors?
[1] http://lightspark.github.io/ [2] https://en.wikipedia.org/wiki/Gnash
Here's Unity's recent benchmark of WebGL and asm.js to see how performance has improved and will improve further in future: http://blogs.unity3d.com/2015/12/15/updated-webgl-benchmark-...
I'd be interested to see some more recent Flash versus asm.js benchmarks if anyone knows of any.
So they ignore all the things the user waits for, and focus on the frame rate that can be achieved once it's loaded. Bearing in mind that the most likely use of this feature is in ads, not twitch games, that's the wrong metric.
http://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-fe...
https://archive.org/details/softwarelibrary_msdos_games
https://archive.org/details/sega_sms_library
https://archive.org/details/internetarcade
Or video and audio codecs as used by Wikipedia to support those browsers which don't support those codecs natively:
https://github.com/brion/ogv.js/
https://brionv.com/log/2015/08/09/video-decoding-in-the-java...
Also try Bejeweled. A simple game but well executed:
http://bejeweled.popcap.com/html5/0.9.12.9490/html5/Bejewele...
In future we will have than binary asm blobs that run web apps faster and outperform any normal JavaScript. Then we will have to compile JavaScript to WebAssembly to get the extra performance boost, right? Stupid! It seems this technology is very bad for the whole web eco system.
How about investing more time in advancing HTML5? Little has been done since 2012.
So there's been a bunch of work on Custom Elements, Shadow DOM, ES6 modules, HTML Imports, ES6 proxies, Custom style & layout & paint (this part is still pretty early), etc
Mozilla OdinMonkey is used for asm.js, it's a seperate engine in Firefox (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.
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.
"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."
[1] We all write terrible code in professional setting. It is unavoidable. And scripting makes writing terrible code faster and easier than ever before.