5 ms·

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) t

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 3y ago
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 3y ago
  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.
  - catlover76 3y ago
    > 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 3y ago
      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 3y ago
        Oh I didn't even think of that--that sounds like a huge pain in the ass lol
  - ReleaseCandidat 3y ago
    > 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 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 3y ago
      How is allowing WebAssembly to use the network any less secure than allowing JavaScript to use the network?
      - ReleaseCandidat 3y ago
        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/ https://webassembly.org/docs/web/
      - lxgr 3y ago
        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.
    - sebastianz 3y ago
      But you will be able to do network access though the fetch API, and fs access though its own API.
- zarzavat 3y ago
  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 3y ago
  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

Philip-J-Fry 3y ago

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 3y ago
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.
- catlover76 3y ago
  > 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 3y ago
    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 3y ago
      Oh I didn't even think of that--that sounds like a huge pain in the ass lol
- ReleaseCandidat 3y ago
  > 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 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 3y ago
    How is allowing WebAssembly to use the network any less secure than allowing JavaScript to use the network?
    - ReleaseCandidat 3y ago
      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/ https://webassembly.org/docs/web/
    - lxgr 3y ago
      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.
  - sebastianz 3y ago
    But you will be able to do network access though the fetch API, and fs access though its own API.
zarzavat 3y ago
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 3y ago
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