> Afaik WASM even in the browser does not allow modifying the blob after instantiation.

...not your own WASM blob, but you can build a new WASM blob and run that.

> The thing you are referring to puzzles me as well...

Yes, compilers emit WASM, but that WASM is just a bytecode (similar to JVM or .NET bytecode but even higher level because WASM enforces 'structured control flow') and needs to be compiled to actual machine code on the client before it can run, and this isn't a simple AOT compilation - in browsers at least (it used to be for a while in Firefox, but that caused issues for large projects like Unity games, which might take dozens of seconds to AOT compile).

AFAIK all browsers now use a tiered approach. The WASM-to-machine-code compilation doesn't happen on the whole WASM blob at once, but function by function. For the first time a WASM function is called, a fast compilation will happen which may have slow runtime performance, from then on, 'hot functions' will be compiled with a higher tier backend which does additional optimization, is slow to compile but has better runtime performance - and AFAIK this is also quite similar to how Javascript JIT-ing works.

Also from what I understand WASM compilation is more complex than just translating bytecode instructions to native instructions. It's more like compiling an AST into machine code - at least if you want any performance out of it.

The only difference to JS might be that WASM functions are never 'de-optimized'.