Namaskar, welcome to another fantastic blog, previously we've tried to work with wasm on the user/client-side and learned its advantages but today ...
For further actions, you may consider blocking this person and/or reporting abuse
I highly disagree with "WebAssembly achieves near-native performance". There's A LOT of issues with WebAssembly, and the proposals to add features just proves that point.
In my experience WebAssembly is almost 5x slower than native (either using browsers, wasmer or wazero). Also, sounds like that is not just me: arxiv.org/abs/1901.09056. Of course, each compiler and language have their responsibility, also the JIT/Runtime... But.... First, WebAssembly doesn't have threads, and the threads proposal is just terrible and only works based on WebWorkers, so only applies for Browsers, kinda of. On Golang, exists issues that only affects WebAssembly, such as this one: github.com/golang/go/issues/42979. Also, Garbage Collected languages (such as Go) needs to stop the program and analyse all references in single-thread, making it even slower. There's also issues related to the lack of stack/heap and linear memory, and also related to the lack of goto. However, one of the most important performance-cost is FFI calls, via Import/Export, which punish the communication between host <-> wasm.
I like WebAssembly, and I use it. But, "near-native performance" isn't true for me, yet. Anything else is fine, it's safe, and it's portable. It's makes possible to have a single lightweight-VM for multiple languages. But, isn't fast.
Hi @inkeliz_35 , hope u r doing well. In this post I've properly specified the advantage of wasm on some particular languages and framewroks and how if it is taken to right direction would help it to get more optimised and useful.
If I talk about your reply it really make sense but we both have two different argumnets in different directions. In the intial stage everything has more disadvanges than advantages but slowly slowly with more clarity and optimisations, things start getting working as they are expected. Hope this will answer.
Check enarx.dev/ they are using wasm on the server side and they'r doing really good.
I never use Enarx, and I personally never heard about them. However, Envoy supports WebAssembly and also defines the "proxy-wasm". They list a lot of pros and cons related to WASM, github.com/proxy-wasm/spec/blob/ma.... The performance and FFI calls is also be biggest drawbacks listed, and in my use-case it also where WASM fails apart, and fails really bad.
The situation might improve in the future, as you said, but it's unknown. We already have WebAssembly 2, which extends the first version.