I've yet to personally find a good use case for wasm in any project, kind of the same way I'm not quite sure what to do with a bunch of Raspberry Pis
It fills a need, I just don't know who/what has that need.
Example: Say I write a bunch of Rust async projects for fun. Scraping APIs, etc.
How/why would I choose wasm/wasmer to do that instead? I'd do it in Rust (awkwardly/in some specific non-standard way) to compile to wasm to then run in wasmer? To what benefit? Ok, that's not a good usecase/example
A toy project, but I'm working on a Scrabble clone for my mother to play. There's singleplayer against an AI, and then multiplayer against other people (myself, mostly). Multiplayer needs a server backend with all the game logic which I have programmed in Rust, but there's no reason I can't have the game logic for singleplayer running entirely in the browser.
By compiling my backend code to WASM I basically do that - the client can use either a client-side 'server' or connect to a real server. The UI code itself is unchanged in either case.
I suppose the need in this case is that I have code written in a language other than JS and I want to run it in a browser; inversely I could have written the entire project in JS and hosted my backend server on say Node.
Did you mean single player? Although perhaps I'm just old and thinking about this in a strange way.
And can I clarify.. your scrabble app is web based already right? connecting to a rust web server for the game logic? And you want to embed that server by compiling to wasm? I probably should go read up on how this works.
Not the OP, but most web-based multiplayer games use a server backend to communicate between the multiple players.
> connecting to a rust web server for the game logic? And you want to embed that server by compiling to wasm?
I would assume so, and it being in WASM means they can use the exact same binary code on the server and in the webbrowser.
You could of course do the same thing by writing in Javascript (running in Node on the server or in the browser) but then you are in JS instead of Rust.
i did almost the exact same thing except i wanted the client to enforce the same logic as the server would without having to do api request on every action or having 2 implementations so i just compiled the library code to wasm and that way both the server and the client share the same logic
history tells us, that usecase will go out the window as soon as the usual suspects do their usual standards capture by implementation to support something or another related to advertising attribution.
> It probably makes sense if you're running untrusted code or handling untrusted data
I never understood this because... I feel like wasm (the standard) is an empty box and a lot of runtimes help you attach things to it / make it useful (able to read/write to filesystem, call the Internet, etc.)
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.
Everyone else has answered about WASM, so I'll answer about raspberry pi. I've got 5 of them. One is running Home Assistant for all my home automation and camera recording. One is running a quadruped that I built. And three are connected to three sets of speakers around the house running a home-rolled Sonos-like setup so I can stream the same music all around the house from my phone.
I think the biggest company using wasm in production is figma (though there might be others). Otherwise, here is an example where wasm shines. Say you have an editor (rvim) and you want to support plugins. Usually, you’ll have a language interpreter and ask developers to develop in this language. With wasm, you can give them the freedom to use whatever stack they want. Then you expose an interface for their wasm artifacts. This abstract the host OS away. Another example is game mods/plugins.
> I think the biggest company using wasm in production is figma (though there might be others)
Amazon uses Rust to wasm for the Prime video app and Google uses Java to wasm for Google Sheets. Both get higher performance and lower memory usage versus JavaScript:
Take that API scraping script example. Imagine next you want to build a platform where you run code written by your users who want to e.g. scrape APIs. Think ParseHub I guess? Zapier is another good example.
You'd let them write in Rust or some other language that can target WASM, then you'd run the WASM blobs in a controlled sandboxed execution environment in your platform.
So basically: what every single platform with plugins should be doing to protect their users. Or similar via some other language that allows sandboxing, e.g. Lua.
OK, OK, it’s a bad example. WASM is language agnostic though, so as more languages can target WASM, then the possible advantage is programming language agnosticism. If I have some code, I don’t have to re-write it in Lua.
Wasm could be a handy way of letting users mod your app using their choice of programming language that can compile to wasm. Compare with how lua is used.
I've yet to personally find a good use case for wasm in any project, kind of the same way I'm not quite sure what to do with a bunch of Raspberry Pis
It fills a need, I just don't know who/what has that need.
Example: Say I write a bunch of Rust async projects for fun. Scraping APIs, etc.
How/why would I choose wasm/wasmer to do that instead? I'd do it in Rust (awkwardly/in some specific non-standard way) to compile to wasm to then run in wasmer? To what benefit? Ok, that's not a good usecase/example
So what is?...