Yep. WebAssembly today is literally just a better/faster asm.js.
The argument against it linked above is nonsense. Most arguments like this that I see tend to fall into one of these boxes:
1. Using wasm as springboard to argue against something else they don't like.
— e.g. disliking closed source code / source obfuscation / minification is a fair position, but it's not helpful to anyone to pretend that wasm introduces anything different here (as has been pointed out, wast's inclusion of type information actually makes it slightly more readable than minified JS).
2. Arguing against something that wasm could maybe one day become.
— Right now wasm doesn't enable anything you can't already do with asm.js, so the idea that it somehow kills JavaScript or whatever is wrong; anything that can compile to wasm can compile to asm.js. Sure, maybe one day wasm will gain DOM/GC/etc. functionality, but asm.js could just as easily gain a lot of the same proposed features. (And wasm/asm.js aside, plenty of languages already compile to JS quite successfully; this hypothetical future wasm would just make them faster.)
3. Seeming to have only a vague sense of what wasm actually is. I think arguments like #1 and #2 have led to a set of talking points that don't at all reflect reality but sound correct to developers who don't have direct experience with asm.js/wasm.
— e.g. the argument from the linked Lobsters comment that "It solves problems that we don’t have. ... If performance is the important thing you pull on your big kid pants and write C/C++/D/Rust and if ... performance isn’t important, you just write in JS." neatly summarises exactly the point of wasm while somehow trying to frame it as an argument against it.
And asm.js wasn't the correct answer either. Nor is minification, as is pointed out in my original comment.
On (1), you're ignoring the fact that asm.js/wasm/low-level languages are in general harder to reverse than uglified high-level stuff. You can see the details perfectly, sure, but emitted compiled code (say, from Duff's device or something) is a lot harder to back out of than the equivalent minified source code--especially when you see crazy shit like "-O 3" would make. tl,dr; compilation != minification, and acting like they are is at best incorrect.
Your (2) fails to address the entire complaint about wasm (aka asm.js) leading to bad things and ecosystem bloat. You just say "well we can kinda already do it", but fail to address any of the substance of the actual argument I made.
Your (3) misses the point completely about "write in native code" and not "write in something that gets run in an interpreter". Like, you've missed the whole point that if you need performance, you need to be writing something outside the browser, and if you don't need performance existing JS is sufficient.
1. Yeah, sorry, I was really speaking in general terms here and should've been more clear about that, as your argument was explicitly that it's just another step in a pre-existing wrong direction, not a big horrible thing all its own. re: wast vs minified JS, the specific comparison I had in mind was with asm.js code, which (minified or not) is from what I've seen less readable than wast.
Generally speaking, my point here was that I think some arguments against wasm conflate a pre-existing state of affairs that aren't liked
with the delta that wasm introduces.
2. Hm, yeah, fair enough. In my mind this all boiled down to "the only significant direct effect of wasm is to make what we're already doing faster", which in itself is obviously good; but that was coming from my bias of being a fan of asm.js, and ignored the other long-term impacts that would inherently come with enshrining all that extra machinery — even just politically blessing what asm.js already accomplishes in most browsers as the officially sanctioned new normal in all browsers isn't nothing if you think it will at least politically help in pushing things further in a bad direction.
I'll have to reread your and other arguments against wasm with a more open mind less stuck on the immediate delta.
And yeah, actual harmfulness or lack thereof aside, it wouldn't help anyone for all this effort and API surface expansion to go into building out a feature that didn't add value ("ecosystem bloat"), so that's a fair point.
3. I got what you meant by that, although on the first read it also sounded like there was some sort of misunderstanding (mostly combined with the "bad vendor incentives" section — it wasn't clear why a vendee would be more likely to accept compiled wasm without source code than minified/obfuscated JS). In any case, I don't see why being required to leave the browser for performance-sensitive code should be considered a feature and not a bug. Wasm presents a very convenient method of sandboxing untrusted code with a high performance requirement.
Agreed that this isn't a concern for typical CRUD apps or documents (although I imagine CRUD apps will ultimately benefit in the form of frontend JS frameworks incorporating wasm in critical paths), and I know I'm definitely in the minority being a beneficiary of asm.js/wasm. However, it's a bit late at this point to unmake all the more complicated applications we've built on the web, and all wasm does is improve a subset of those applications that already exist (as opposed to enabling entirely new applications), so I don't think this is a good argument against it.
The argument against it linked above is nonsense. Most arguments like this that I see tend to fall into one of these boxes:
1. Using wasm as springboard to argue against something else they don't like.
— e.g. disliking closed source code / source obfuscation / minification is a fair position, but it's not helpful to anyone to pretend that wasm introduces anything different here (as has been pointed out, wast's inclusion of type information actually makes it slightly more readable than minified JS).
2. Arguing against something that wasm could maybe one day become.
— Right now wasm doesn't enable anything you can't already do with asm.js, so the idea that it somehow kills JavaScript or whatever is wrong; anything that can compile to wasm can compile to asm.js. Sure, maybe one day wasm will gain DOM/GC/etc. functionality, but asm.js could just as easily gain a lot of the same proposed features. (And wasm/asm.js aside, plenty of languages already compile to JS quite successfully; this hypothetical future wasm would just make them faster.)
3. Seeming to have only a vague sense of what wasm actually is. I think arguments like #1 and #2 have led to a set of talking points that don't at all reflect reality but sound correct to developers who don't have direct experience with asm.js/wasm.
— e.g. the argument from the linked Lobsters comment that "It solves problems that we don’t have. ... If performance is the important thing you pull on your big kid pants and write C/C++/D/Rust and if ... performance isn’t important, you just write in JS." neatly summarises exactly the point of wasm while somehow trying to frame it as an argument against it.