by qclibre22 on 4/10/24, 1:11 PM with 99 comments
by azakai on 4/10/24, 4:14 PM
> With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis.
I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In that sense it's already succeeded.
by DarkNova6 on 4/10/24, 3:16 PM
I wasn't aware a new version of WASI was out. I've been following it for years and its potential is still exciting.
Some quotes:
> WASI 0.2 also introduces two distinct “worlds,” which describe different kinds of hosts that WebAssembly can run on. The first of these worlds is the “command” world, resembling a traditional POSIX command-line application with access to the file system, socket and terminal.
> The second of these worlds is the “HTTP proxy,” which characterizes platforms, like Fastly, that can send and receive streaming HTTP requests and responses, serving as forward or reverse proxies. These worlds represent the beginning of a broader ecosystem, offering developers multiple avenues to explore and innovate, and more worlds will be added to WASI in the future.
by iwillsayit on 4/10/24, 4:02 PM
Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ...
Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attempt at tighter integration with the Browser API stopped in the hope for a magical solution to all computing problems.
by austin-cheney on 4/10/24, 3:51 PM
In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about.
Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise. This line of wishful thinking instills false hope and just pisses off everyone else, which slows adoption among other languages. The Web Assembly effort has been very clear about this from the very beginning, but people believe what they want to believe even after this has been clarified dozens of times.
There are absolutely valid business cases behind Web Assembly though, here are some:
* circumventing iphone restrictions
* desktop application portability
* security
* partial docker alternative
* promoting adoption and access of applications written lesser popular languages
by pjmlp on 4/10/24, 6:47 PM
The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony.
And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other than bringing existing libraries into the browser.
At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.
by aquova on 4/10/24, 3:21 PM
This is the biggest limitation for me. I like WASM fine, but anytime I want to use it I have to turn back to Rust. I like Rust fine, but without support in other languages, it's not necessarily worth diving into.
by throwaway63467 on 4/10/24, 3:14 PM
by JohnFen on 4/10/24, 3:26 PM
That's not to say that I don't see any benefit in it. I can see use cases for it, they just aren't use cases that I have.
by justahuman74 on 4/14/24, 5:34 PM
by 6510 on 4/10/24, 5:30 PM