Skeptical of rewriting JavaScript tools in "faster" languages

On the server, you wouldn't choose wasm, you'd choose a language that compiles to wasm. Which is really just saying "choose another language": there's no point in compiling (e.g.) Rust to wasm just to run it with Node on the server.

You'd choose wasm on the server if you're using a framework that supports it. For example:

https://blog.nginx.org/blog/server-side-webassembly-nginx-un...

https://github.com/WebAssembly/wasi-http

Write in any language, compile to WebAssembly, have it run on the server no matter what the server's CPU architecture, achieve better performance with high compatibility.

Why in the world would you compile to wasm and make your code slower instead of just compiling to native code? To your example: you don't need nginx to talk to wasm, it already talks to your code running on a local socket.

The only reason for wasm is portability. If you can't compile your code for the server you're going to be running it on, then the original argument of choosing wasm over JavaScript is already moot.

> instead of just compiling to native code?

Because the managed service you signed up to doesn't offer that to you. They like WebAssembly modules because it's a sandboxed runtime.

It's an awfully silly choice to use a managed service that only offers JavaScript and wasm if you don't want to use JavaScript and you care enough about performance that you're willing to accept the fairly meager benefits of wasm over JS. The real reason you'd choose wasm in this case is "I don't want to use JavaScript and I'm otherwise forced to use this service".

Or the price is right.

Come on down! Use WebAssembly. You'll love it.

Use Plinko https://github.com/jart/cosmopolitan/tree/master/tool/plinko

Back in the 1980s it was my greatest ambition to go on The Price Is Right and play Plinko. However all I could accomplish was making this cursed programming language instead. You'll love it.

A quick skim suggests that this framework re-inititalizes the sandbox on each request (so there's no shared context across requests). That's not going to achieve better performance.

Phew! Thank goodness you skimmed it! For a minute there I thought the NGINX developers knew something you didn't.

I'm basing my statement on what they wrote:

> The WebAssembly sandbox’s linear memory is initialized with the HTTP context of the current request and the finalized response is sent back to the router for transmission to the client.

They can feel free to clarify that multiple requests can concurrently use a shared context as well if that's true. Or if that's not true, then the thing will of course be slow assuming it needs to do some kind of IO like a database request.

Note that major FaaS implementations like AWS Lambda don't let you have concurrent requests that share context, so it's not exactly crazy to think this wouldn't either.