Maybe nitpicking, but that's not quite right. The Workers Runtime is a separate process from nginx and is inside a heavy second-layer sandbox separating it from the rest of the system. Multiple Workers Runtime instances exist on each machine to serve different tiers of customers, and each instance may additionally create further subprocesses to provide extra sandboxing adaptively.
Here's a diagram: https://blog.cloudflare.com/mitigating-spectre-and-other-sec...
(In that diagram, the "Inbound/Outbound HTTP Proxy" boxes are, at least at present, nginx, but the big middle box is a new server architecture written from scratch.)
This is a better question, actually, if you already have a codebase in another language that can you can easily compile to wasm, but not to javascript.
Well no right? I have website. I don’t have mobile app that just needs to switch platforms.
Do you have a website built in another language already? Then sure, all you need to do compile it via WASM. What I bet most of you have is a program for a totally different platform. In that case, you have to redo it, so why not just do it right.
* A wide ecosystem of mature language toolchains.
* Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator.
* Portability: not tied to a specific HW architecture.
"A wide ecosystem of mature language toolchains." - yes, for Javascript, not for WASM, which isn't deployed really anywhere in production and there aren't even best practices for it.
What language are devs going to even write these scripts in? That's not clear.
"Simplicity" - nothing is more 'simple' than JS, which is why it's used the world over.
"Portability" - again, nothing more portable than JS.
The reasons to use WASM are 'performance' along with 'black box' - but in most cases performance is not necessary and the black box for all intents and purposes exists with v8.
Not in terms of implementing the language.