I have no personal experience with Wasmer or the people behind it. But with the things I read about them (e. g. https://mnt.io/2021/10/04/i-leave-wasmer/ crossed my path again a few days ago) would make me, to put it lightly, hesitate before building on it.
Thanks for providing the link, readers can probably judge for themselves by checking the comments there if blocking someone just for having a different point of view was the right thing to do by the Zig leadership team
Clearly, they are not compliant with WASI specifications built by the ByteCode Alliance, creators of WebAssembly. They are making their own web-assembly-thing not compliant with anything.
It feels very close to docker equivalent for WASM binaries which is very cool.
I think this might be the breakthrough required to make wasm server-side very mainstream. I think there is still complexity and standardization issues on compilation side. When that is solved then server-side wasm would be ready for democratization I think.
The technology is interesting, but I've never bothered to install it. It seems like this ecosystem is missing compelling reasons to use it, sort of like a device or app store that's missing interesting apps.
The demo they put on the front page doesn't really sell it. I already have Python installed. It's need that they got it running, but how is this better?
What would sell it? Suppose there were a well-regarded hosting site that required uploads to be WebAssembly. Or maybe some popular app that required plugins to be written in WebAssembly.
> By extension, a headless engine can only execute a WebAssembly module, i.e. a module that has previously been compiled, or compiled, serialized and deserialized.
This offers the potential of using WASM w/ go (or any other language I expect) to create the equivalent of Erlang's "Universal Server". Ie. create an API that receives the code necessary to "become" another API.
I'm probably holding it wrong, but the website has a dropdown for CLI, but CLI is the only option in that dropdown, which is at odds with "Run... anywhere" in the headline.
That widget is wonky for me too, but if you go to the runtime page (https://wasmer.io/products/runtime) you'll see SDKs for Rust, Python, JavaScript, Go, Ruby, and C.
There is a package that "contains a WordPress website that can be run as a WCGI program by Wasmer"[1]. But there is now WordPress Playground: A WordPress that runs entirely in the browser[2]. I wonder if Wasmer will continue to develop their own WordPress browser implementation?
>I wonder if Wasmer will continue to develop their own WordPress browser implementation?
I think it's probably meant more as a demonstration of "run, publish and deploy any code, anywhere" rather than as a serious use case suggestion. It's taking something people are familiar with, know to be a bit messy and complicated and running it in a browser.
Readit News
Context: https://news.ycombinator.com/item?id=37545192
As a matter of fact we pass more tests than any runtime created by the BA as reflected here:
https://wasi.fyi/
I assumed they were compliant with the WASI specifications.
Wasmer 1.0 https://news.ycombinator.com/item?id=25649476 (161 comments)
Wasmer 2.0 https://news.ycombinator.com/item?id=27537541 (56 comments)
Wasmer 3.0 https://news.ycombinator.com/item?id=33721685 (183 comments)
I think this might be the breakthrough required to make wasm server-side very mainstream. I think there is still complexity and standardization issues on compilation side. When that is solved then server-side wasm would be ready for democratization I think.
The demo they put on the front page doesn't really sell it. I already have Python installed. It's need that they got it running, but how is this better?
What would sell it? Suppose there were a well-regarded hosting site that required uploads to be WebAssembly. Or maybe some popular app that required plugins to be written in WebAssembly.
1: https://www.fermyon.com/spin 2: https://www.fermyon.com/cloud
https://pkg.go.dev/github.com/wasmerio/wasmer-go/wasmer
> By extension, a headless engine can only execute a WebAssembly module, i.e. a module that has previously been compiled, or compiled, serialized and deserialized.
This offers the potential of using WASM w/ go (or any other language I expect) to create the equivalent of Erlang's "Universal Server". Ie. create an API that receives the code necessary to "become" another API.
We are planning to add more languages there once the SDKs are fully ready... stay tuned :)
[1] https://wasmer.io/wasmer/wcgi-wordpress-demo
[2] https://news.ycombinator.com/item?id=36726593
I think it's probably meant more as a demonstration of "run, publish and deploy any code, anywhere" rather than as a serious use case suggestion. It's taking something people are familiar with, know to be a bit messy and complicated and running it in a browser.