I don't think the downvotes are necessary here, this is a legitimate question.
Understand that Wasm is ideally just an alternate way to drive the same virtual machine that Javascript currently manipulates. This isn't the same thing as, say, a NPAPI plugin like Flash was. Wasm is still subject to the same security restrictions as the rest of the web platform.
Furthermore, and I could be wrong here, but I believe that the "binary" representation of Wasm is really just custom, trivially-reversible compression for faster data transfer and parsing. The OP even mentions that a "standard textual representation" is the next step on the agenda, which I imagine will work similarly to today's source maps for code that compiles to Javascript.
Well "just a binary representation" in the same way that .Net's CLR is just converted C#/VB/F# etc...
Unless you know the source language, and have some sort of reverse-compiler (or source maps), then getting back to a readable/usable source isn't so easy. Though that doesn't mean you can't trace through what goes down the wire, it won't be quite as low-level as x86 assembly, but will be lower level than most are comfortable with.
But this is already true today with Javascript transpilation and minification. I have been in the unenviable position of needing to reverse-engineer compressed Javascript for which no "readable" source was available, and even with prettifiers the experience is hardly enjoyable.
Absolutely agreed... one of the reasons that source maps are nice... but if you nuke sourcemaps in production, good luck...
If it's someone else's source, then you may be SOL, just the same, it is what it is... if you're reverse engineering a gui, best bet is to create a clone... if it's an api, better to look into the wire protocol.
Understand that Wasm is ideally just an alternate way to drive the same virtual machine that Javascript currently manipulates. This isn't the same thing as, say, a NPAPI plugin like Flash was. Wasm is still subject to the same security restrictions as the rest of the web platform.
Furthermore, and I could be wrong here, but I believe that the "binary" representation of Wasm is really just custom, trivially-reversible compression for faster data transfer and parsing. The OP even mentions that a "standard textual representation" is the next step on the agenda, which I imagine will work similarly to today's source maps for code that compiles to Javascript.