4 ms·

Dumb question time: I am assuming that browsers come with a pre-installed wasm engine, and that this can't easily be replaced with a 3rd party one. I therefor

Dumb question time: I am assuming that browsers come with a pre-installed wasm engine, and that this can't easily be replaced with a 3rd party one. I therefore assume that this product does not run in a browser, but rather standalone, and therefore probably on the server ... That brings up the following, likely dumb question: what is the use case?

schemescape 4y ago
I’m not an expert, but you could drop the same WASM binary on servers of any architecture, provided the runtime is installed. I also assume (hope) this runtime is much lighter weight than e.g. Node or Ruby or Python or whatever is popular. It also seems nice because of the sandbox aspect, similar to how I’d rather run a random tool in my browser than give it unfettered access to my local resources by default.
bbatchelder 4y ago
Universal bytecode that is architecture agnostic. Take some rust code, compile it into wasm, and call it from dotnet. Compile your app into wasm and run it anywhere on any architecture. At least that is the end goal as I understand it. The idea of it also being really fast and safe is an extra bonus.
- pjmlp 4y ago
  The idea is as old as UNCOL (1958). https://en.m.wikipedia.org/wiki/UNCOL https://en.m.wikipedia.org/wiki/UNCOL
callahad 4y ago
Same as with Node. Take some browser tech, remove the browser, find out it's useful on its own. Browsers are really good incubators for fast, secure runtimes. Every time you open a new tab, that engine has to run untrusted, third-party code provided by the website. And it has to do start up so quickly that you don't perceive it. Turns out those properties are useful on the server, too.