1. WebAssembly will support "View Source" [1].

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

You have no idea how hard Asm.js is to "read". Minified JS is okayish. But Asm.js has the ASM name in it for a reason, without proper tools it's even harder to read than any ASM. And WebAssembly is at the moment based on Asm.js in its current alpha state.

> You have no idea how hard Asm.js is to "read".

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.

WebAssembly is still work in progress, isn't it? There are proposals to have 2 text formats: low level one (Asm.js like) and more high level representation [1]. So, I'm dead sure the way out will be found. If not, community will create workaround-ish solutions in a form of "WASM -> language of your choice" decompilers.

[1]: https://github.com/WebAssembly/design/pull/457

I feel like this raises an interesting question. I feel like it is a good thing that one can read the source of any of the code running in your browser, since it is all Javascript. However, I also don't like the fact that Javascript is the only option for web development. Other languages would be useful in that space as well. I wonder if browsers could somehow necessitate the inclusion of source? I doubt it is possible though, because it require the browser essentially compiling the code again, which would require special handling for each supported language, defeating the purpose of web assembly in the first place. (Also I'm not sure that transpiling other languages to minified Javascript is better than compiling to an assembly language with a sensible textual representation.)

Asm.js and WebAssembly are meant for C++ or languages in which the memory management is manual. Garbage collected languages don't work, unless you implement the GC in asm.js as well. And at that point it's far better to compile that language to plain Javascript.

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.

Getting a bit off-topic here, but since I have been wondering about what makes "transpiling" different from the existing word of "compiling", would you say that proper usage would be "reversible compilation with zero loss of information"?

> would you say that proper usage would be "reversible compilation with zero loss of information"?

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.

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

There will be a very few really good applications of this. But this will be used mostly to obfuscate code that's doing something hostile to the user.

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

PLEASE never use "You could do most of this stuff in Flash" as an argument against WebAssembly or, uh, any other technology. Flash is a 3rd party, closed source, proprietary plugin. Aspiring to replace it with something slightly better at the very least is worth doing.

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?

There are non-Adobe Flash players. The format is well understood. Some commercial video games use Flash for the non-3D GUI. They don't use Adobe's player, but they use Adobe's authoring tools, which are graphics-artist friendly.

[1] http://lightspark.github.io/ [2] https://en.wikipedia.org/wiki/Gnash

Isn't the difference with Flash is that you have a pre-loaded proprietary blob already (the player).

But asm.js (and WebAssembly) runs faster than Flash. See a couple of different benchmarks from 2013 (http://www.j15r.com/blog/2013/04/25/Box2d_Revisited) and from 2014 (http://www.infognition.com/blog/2014/comparing_flash_haxe_da...). asm.js also outperformed Dalvik in 2013: https://blog.mozilla.org/javascript/2013/08/01/staring-at-th...

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.

From the benchmark description: "This version has been stripped of all of the artwork and eye candy we had in the previous version." "This is running content from a local disk, so the time to download files from the network is ignored."

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.

Do you have any such download comparisons between Flash, asm.js, and WebAssembly? WebAssembly reduces the download size and speeds up the load time versus asm.js. See Unity's testing:

http://blogs.unity3d.com/2015/06/18/webgl-webassembly-and-fe...

As for good applications, how about running DOS, MESS and MAME in your browser? It's a nice archive.org feature:

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

Google does it right with optimizing v8 for general Javascript usage. Mozilla especially optimizes for Asm.js, they detect asm.js code route that code not to their general purpose Javascript engine but to a seperate JIT written for asm.js. Bad idea, as we will find out.

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.

A bunch of work since 2013 has been in filling out the foundations of the web platform, so that as many new features as possible can be added by web devs first, and standards committees afterwards if necessary. This initiative is called the extensible web: https://www.w3.org/community/nextweb/2013/06/11/the-extensib...

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

This view neglects the fact that Google was pushing PNaCl during the "Why Asm.js Bothers Me" time.

Compiling from JavaScript to WebAssembly is not possible and makes no sense.

https://github.com/WebAssembly/design/issues/219

Bla bla wrong.

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.

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

Minified/obfuscated js already makes code disassemble hard. And the majority[1] of the code out there is already terrible - the mess of jquery and callbacks, plugins and 4 MVC and 6 reactive frameworks makes it impossible to understand.

[1] We all write terrible code in professional setting. It is unavoidable. And scripting makes writing terrible code faster and easier than ever before.