4 ms·

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

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.

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.