that would have been implement in something like forward only language like ebpf. wasm is just an outgrown hack that people are hopping will be that safe sandbox and solve all JavaScript problems.
do not fool yourself with this temporary feature. wasm was first for js performance. secondly for portability. and third and accidentally for sandbox.
> that would have been implement in something like forward only language like ebpf. wasm is just an outgrown hack that people are hopping will be that safe sandbox and solve all JavaScript problems.
It's funny that every time an article on new functionality for eBPF appears in LWN everybody is like "why don't they just use WASM???". More seriously, a forward only language is by definition too strict for the general case of sandboxing, unless you mean using it only for hooking the syscalls rather than as a target for your program. In particular, the Linux implementation caps your execution to 1M instructions, which is not a lot for something you'd want on your browser.
> 1) Making canvas webapps with unblockable ads built-in
Which isn't any different from Javascript if you choose to embed the ads right into the Javascript code - but nobody does this because it doesn't make any sense.
In reality, a WASM app that displays ads would also need to load the ad content over one of the existing ad-network mafias (serving ads any other way simply doesn't make any financial sense), and those HTTP requests initiated by a WASM blob (by calling out into JS - because that's the only way in browsers) will be blocked just as fine by existing ad-blockers.
...but I'm also not actually aware of any webpage that does this (trying to defeat ad-blockers via wasm), do you have any example?
For sandboxing in JS, we can use sandboxed iframes or webworkers. Both of those communicate to hosted code via postmessage which serializes an object and this can be used as a base for implementing function calls.
Whereas if I understand correctly, WASM can be provided with host approved JS functions to call directly in importObject. This seems more convenient and fast.
But for a plugin system, many people would prefer to write plugins in JS itself, so for WASM plugins, they might have to be compiled to WASM first. Dont know how if there is a mature implementation of JS->WASM.
> But for a plugin system, many people would prefer to write plugins in JS itself, so for WASM plugins, they might have to be compiled to WASM first. Dont know how if there is a mature implementation of JS->WASM.
Not everyone tho, which is kinda the point of abstracting away your language for plugins. People like Python, Lua, Go, Rust, etc... Some do like JS of course, but not everybody.
Re: mature implementations, I would guess worst case QuickJS probably can compile to WASM and it's small enough that your runtime will probably offset the extra blob size.
1) Making canvas webapps with unblockable ads built-in
2) Downloading and running random blobs of other people's code in a sandbox