[yebyen]

> isn't feasible

This is kind of subjective, and in the context of "is this a JS killer" which is what you're answering, I'd agree, it makes sending the Wasm to the browser a bit of a non-starter that it requires a large bundle most of which is simply boilerplate for whatever runtime, without some type of local storage and persistent cache it's difficult to imagine using Ruby in a Wasm for example. If you're deploying to a container, where you're able to use a cache warmer to ensure the wasm is ready before it's called, then a 1mb binary might not be such a big issue.

(I mean, it is still a big issue because the point was fast cold starts, and big assemblies mean no fast cold starts, but again, subjective value judgments... 1mb isn't too big in many cases and I'd wager most of the cases that I'd really care about. But in a browser...)

But if you're not trying to run the Wasm in a browser then it's still potentially quite useful. You might not be running all of your Wasm in a browser and it might still be a JS killer, and all of those might not be in conflict.

[ReleaseCandidat]

Well, the main reason why I'm taking a deeper look at WASM is because I'm creating a language and compiler that is optimized to compile to WASM. While I don't think that my compiler will be the JS killer, I do think that WASM languages using a (the WASM) GC have a future.