Just because its binary doesn't mean it can't be studied. Even with something like compiled native machine code its still relatively easy to disassemble and look at how it works with the right tools. With WebAssembly, dissassembly should be even easier and be more clear than native x86 or something. Still not as easy as well written javascript, but I expect it will approach the difficulty of minified js.

In my eyes, the size and offline compilation aren't even the biggest benefits. Having a low level assembly language for web computation lets people write in any language and compile it for the web. There's already an LLVM backend for it - although still experimental. But this may even mean we can simply port existing codebases to WebAssembly with little performance loss.

You've been able to compile stuff for web for a while, by transpiling to javascript, but the result has been too slow for many applications, so it never really picked up.

> I expect it will approach the difficulty of minified js.

WebAssembly has less structure than minified JS (instructions are a linear list - a stack machine - for example) and it is less hackable (it isn't intended to be written or modified by hand).

WebAssembly will be somewhere in between native x86 and minified JS in terms of how open it is to being studied.

You have asmjs working well for 3 years to cover your usecase. WebAssembly is not really faster to execute than asmjs in our tests.

> since network, cpu's, and memory sizes are going to continue to improve.

As the article mentions, the drastic speed improvement that JIT gave us let us build even bigger, more complex web apps. Maybe things will continue to get bigger and more complex and we'll need wasm, or maybe wasm will allow us to build apps not possible now.

> I've found that even the most aggressively minified uber-scripts can be pretty printed and studied.

I haven't found this to be the case. Most minifiers rename variables to one-letter, which makes any moderately-complex web app unreadable, or at least not very fun. Furthermore, I don't think that technically requiring source-code distribution for execution is really the solution - Open Source is a social problem at root, not technical.

I, for one, welcome the possibilities.

If I understand webassembly, to me the main benefit will be to precisely code in a language other than javascript. Some people love javascript, like others love C or assembly. I personally prefer high level statically typed languages, where the IDE can help me a lot, do refactoring, checks for syntax errors, etc. Then we will have the equivalent of a JVM or CLR but truly cross platform (if Apple plays the game).

For purposes of pretty-printing and studying, the WASM MVP is effectively a binary encoding of asm.js. Imports and exports have names and are statically defined, while the degree to which unexported symbols are mangled is determined by your compiler settings.

Debugging tools will need to improve, and you'll need to learn WASM's (limited) vocabulary, but if you're happy enough with asm.js, then I think you'll be ultimately be happier in the future. I, for one, would much rather see actual type signatures like: "param $x i32" than asm.js's cryptic annotations "x = x|0".

> I wish the scripting line would not be crossed and we could stick to JIT-compiled JS or even dialects that can execute closer to the metal (like asm.js). It's just so nice to be able to have all the codes ...

This is addressed in the WASM FAQ:

"Will WebAssembly support View Source on the Web?

Yes! WebAssembly defines a text format to be rendered when developers view the source of a WebAssembly module in any developer tool..." [1]

[1] http://webassembly.org/docs/faq/

There will be a text format, but it's important to keep expectations low, as here is what it looks like:

http://webassembly.org/docs/text-format/

I suspect that's no worse than minified JavaScript or ASM.js.

That's a joke, right?