And currently using anything but C, C++ or Rust isn't feasible, as the runtime needed for a GC is way too big. A Haskell "Hello World" for example is about 1MB (even after running `wasm-opt` on the generated WASM binary).
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.
But you need the WASM thread extension (for atomic access to the shared memory) to be able to use shared memory.
Someone should tell Anaconda that they can't do this, then: https://pyscript.net/
"At present a first load of Pyodide requires a 6.4 MB download, and the environment initialization takes 4 to 5 seconds."
So, yes, it works. But there's plenty of situations where a big download followed by a 5 second stall is a non-starter.
Let WASM do the number crunching, let JS do the UI.
For a lot of companies the only place JavaScript is ever used is on their website frontend. And it makes you wonder, why does it even still need to be JavaScript? With the rise of SPAs and the fall of normal document based websites, browsers are basically just becoming their own platform like Windows Desktop, Mac, Linux, Android, iOS, etc. You could say it's been that way for a long time, but more and more apps are becoming web based only because the browser is now powerful enough to run what used to be a desktop application.
Browsers are literally just a VM with an address bar. We go to a URL and run a program, except right now there's basically the limitation that the program has to be written at least partly in JavaScript. Being able to deploy an entire website as WASM is just the next logical step from what I see.
DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml.
In the meantime, WASM has real, just not for front end dev.
The two language problem is hardly unique to web dev. It’s also ubiquitous in the machine learning/data science space with Python and C/C++/CUDA playing the roles of JS and WASM, respectively.
You don't like Bonsai? Or do you just want something that doesn't "transpile" to JS at all?
DOM is not enough for that. You almost certainly would like to be able to communicate with your backend ;)
Here is a list of the "usual" web APIs: https://developer.mozilla.org/en-US/docs/Web/API And everything that needs network access or access to local resources (file system in the worst case) will never happen to WASM because of security considerations.
At least WASM will get DOM access (and hopefully access to similar web APIs) as soon as the GC is stable and usable.
Once GC is supported, WebAssembly code would be able to reference and access JavaScript, DOM, and general WebIDL-defined objects.
Personally I think that enforcing the SOP at all cost (and even when no cookies or other authentication headers are injected by the browser) is misguided at this point and holding back modern webapps.
The biggest problem is tooling. You cannot build tooling for in-browser WASM because it runs in a browser sandbox. JS has the same problem but the difference is that JS has a known object model that the browser can provide good tooling for.
Whereas with WASM the browser has little insight into what those opaque Memory objects contain. So you need to bring your own tooling and run it inside the sandbox, and the sandboxing does not make this easy.
Let’s say for example you want to pause execution, inspect the object tree, and run a REPL while it’s paused.
not syntax-wise just community wise, where the package and package managers are a mess and why there is demand for a JavaScript killer
I haven't really explored WASM hands-on (I'll give this guide a try) but, given that it's already been a few years, I think it's been hugely beneficial for web development.
Not the "JavaScript killer" some where hoping for, though it was never meant to be one. Instead it integrates pretty nicely within the existing ecosystem, optimizing existing use-cases and allowing new ones when heavy computations are required. Net benefit for all web devs - faster libraries, impressive dev tools and more portable node binaries.