WASM is a non-starter for most web applications due to initial binary download.
Advising to use some experimental feature in one browser does not seem like a great idea.
JavaScript frameworks are not perfect but they exist for good reasons. People that brush them away usually lack the experience and understanding on the topic.
const binary = Uint8Array.fromBase64(
"AGFzbQEAAAABBgFgAX8BfwMCAQAHBgECeDIAAAoJAQcAIABBAmwL"
);
const module = new WebAssembly.Module(binary);
const instance = new WebAssembly.Instance(module, {});
console.log(instance.exports.x2(3));
It seems like you're extrapolating from things you know to something you don't know at all, and you're spreading misinformation. WASM was designed to be compact.
The thing is to get these optimizations, like variable length encoding and tightly packed structs, engineers had to work hard, while a dumb text format gives it for free.
Additionally, they gave up the biggest advantage of binary formats - that they can be mmap-ed directly and read from code.
We'd have to get pretty specific to have a real bake-off on size, and that's probably more effort than either of us wants to spend for a HN thread that's basically dead. I could invent scenarios where either of JS or WASM has the advantage.
Code-golfing that particular example though, the JS could be "const x2=a=>2*a;" (15 bytes). If you ignore the one-time (insignificant) costs for the WASM headers and sections, the comparable byte code for that export is about the same number of bytes. If JS wins, it doesn't win by a lot.
Maybe I misunderstand, but I'm not sure I see the point about hard working engineers or memory mapping. I'm sure the JavaScript JIT engineers had to work really hard to get good performance. Among many other things, JS Objects using "shapes" or "hidden classes" was a pretty clever way to compensate for not having structs at all. For both JS and WASM, end developers don't need to worry about it, and you can't mmap JS to execute the code either.
I was just saying, in my experience, binary formats tend to be easier to parse than text, relying on machine native constructs such as binary integers, sometimes even matching up their stored formats to C struct layouts (this is the case with, Linux's inode format for example).
Whereas complex textual formats such as JSON or Javascript usually have a tokenization and parsing pass. But they are mostly human readable in exchange, which is a ton more engineering effort to build and CPU time to run.
I was just trying trying to say, that once you really get into sophisticated binary formats, you have to take on similar levels of complexity to parsing something like a programming language, meaning that the parser is not simple, or fast, but the file is not human readable either. Which is kinda the worst of both worlds, and doesn't really drastically reduce file size.
TLDR: Text-based formats are fine, expecially for complex data, and are surprisingly competitive with hand-tuned binary formats.
I've written a lot of text parsers for pet programming languages and other things, and several binary parsers for work related stuff. I agree that bad binary formats are really awful. I don't remember the details now, but I gave up on trying to deal with Matlab data files.
WASM made it pretty easy to parse though. Kind of like TIFF or WAV files, the section type and length is right there when you need it even if you're streaming, and it's easy to skip sections you don't know or care about. There's a little bit of error-prone grossness having both unsigned and signed LEB128 inside of some sections though.