4 ms·

> I hope WebAssembly will not only be a web technology, but the de-facto format for cross-platform high-performance embedding. I don't think that's what's happ

by jmull 8y ago

> I hope WebAssembly will not only be a web technology, but the de-facto format for cross-platform high-performance embedding. I don't think that's what's happening. They are looking to integrate webassembly more deeply with its host environment (which more-or-less assumes a browser and Javascript). I don't think this is a bad thing, BTW. You may be disappointed, but they are just looking to solve a different problem then what you are concerned with. It's an imminent, practical problem, so nothing wrong with someone addressing it, even if it isn't your problem.

kodablah 8y ago
Disagree. Watching all of the WebAssembly discussion around proposals and the spec in the GitHub issues, the leads are always mentioning non-web uses and are always being careful to separate the JS/Web ifaces/impls.
- jmull 8y ago
  I guess we'll see, but integrating with the host garbage collector is pretty suggestive, to me. Aside from that, an app/program/whatever delivered as webassembly will typically have strong dependencies on the target host environment, which means its not portable or cross-platform. It's not useless, since you still get to choose your own language for any target that supports webassembly (assuming things work). But code, whatever language its written in, is very strongly influenced by the frameworks & patterns provided/imposed by the host environment, by environmental constraints, not to mention the problem domain itself. E.g., assume there are bindings for any language you want... if you write a To-Do app for iOS using native controls, it's going to look pretty similar whatever the language. > ...and are always being careful to separate the JS/Web ifaces/impls I'll just point out that this is quite important if your goal is to cleanly extend browsers. You specifically don't want to duplicate or impinge anything the browsers already provide. I'm not trying to be a downer, but it seems like people are hoping/expecting webassembly to do more than it can or will (maybe I'm wrong, but that's the impression I'm getting). Meanwhile, we have a very solid use case for it, which is a much better compile target than Javascript for whatever language you might want to use for web development.
steveklabnik 8y ago
Strong disageee, the spec was carefully written to not assume a browser or JavaScript. It’s “host bindings” and not “web platform bindings” for a reason, you know?

by jmull 8y ago

kodablah 8y ago

Disagree. Watching all of the WebAssembly discussion around proposals and the spec in the GitHub issues, the leads are always mentioning non-web uses and are always being careful to separate the JS/Web ifaces/impls.

jmull 8y ago
I guess we'll see, but integrating with the host garbage collector is pretty suggestive, to me. Aside from that, an app/program/whatever delivered as webassembly will typically have strong dependencies on the target host environment, which means its not portable or cross-platform. It's not useless, since you still get to choose your own language for any target that supports webassembly (assuming things work). But code, whatever language its written in, is very strongly influenced by the frameworks & patterns provided/imposed by the host environment, by environmental constraints, not to mention the problem domain itself. E.g., assume there are bindings for any language you want... if you write a To-Do app for iOS using native controls, it's going to look pretty similar whatever the language. > ...and are always being careful to separate the JS/Web ifaces/impls I'll just point out that this is quite important if your goal is to cleanly extend browsers. You specifically don't want to duplicate or impinge anything the browsers already provide. I'm not trying to be a downer, but it seems like people are hoping/expecting webassembly to do more than it can or will (maybe I'm wrong, but that's the impression I'm getting). Meanwhile, we have a very solid use case for it, which is a much better compile target than Javascript for whatever language you might want to use for web development.

steveklabnik 8y ago

Strong disageee, the spec was carefully written to not assume a browser or JavaScript. It’s “host bindings” and not “web platform bindings” for a reason, you know?