[math_dandy]

Is being a "JS killer" even a goal of WASM? From what I understand, WASM's goal is to allow computationally heavy workloads (e.g., image and audio processing) to the browser by providing a compilation target for C code. This is how we get nice things like Figma or MS Office running in the browser.

Let WASM do the number crunching, let JS do the UI.

[Philip-J-Fry]

It's not the goal from what it seems. But it's definitely what would make it the most interesting to a lot of people, and it's what I think most people expected at some point.

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.

[math_dandy]

The two language problem is, indeed, awkward.

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.

[ReleaseCandidat]

> DOM bindings in WASM would be awesome. I would be a happy nerd if I could do all of my web dev in OCaml.

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.

[xigoi]

How is allowing WebAssembly to use the network any less secure than allowing JavaScript to use the network?

[lxgr]

The issue here is the same-origin principle, which rules out most low-level networking (since you could just bring your own SOP-ignoring HTTP client).

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.

[ReleaseCandidat]

Don't ask me :).

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.

https://webassembly.org/docs/web/

[sebastianz]

But you will be able to do network access though the fetch API, and fs access though its own API.

[catlover76]

> I would be a happy nerd if I could do all of my web dev in OCaml.

You don't like Bonsai? Or do you just want something that doesn't "transpile" to JS at all?

[math_dandy]

I find that these compile-to-JS languages are great until you want to bring in other JS libraries. Then you’re stuck writing bindings which is annoying, and often brittle if you’re not really careful.

[catlover76]

Oh I didn't even think of that--that sounds like a huge pain in the ass lol

[zarzavat]

You can certainly bridge the DOM to WASM with a virtual DOM. The problems with WASM are not just interoperability.

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.

[yieldcrv]

If it was the JavaScript killer it will attract JavaScript devs and they’ll make it just like JavaScript

not syntax-wise just community wise, where the package and package managers are a mess and why there is demand for a JavaScript killer