3 ms·
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 al
by 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 agoI 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.