14 ms·

I have a question about WebAssembly. 1- With WASM, would developing for the web become similar to how desktop apps are written? For example, could I use C# and

I have a question about WebAssembly. 1- With WASM, would developing for the web become similar to how desktop apps are written? For example, could I use C# and design a UI in xaml, compile to WASM for the web? 2- No more JavaScript?

spankalee 10y ago
WASM doesn't have access to the DOM, or a GC, or very easy interop with JavaScript, so the answer is mostly "no".
- stupidcar 10y ago
  All that is planned though, just not for the MVP: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
  - mintplant 10y ago
    No idea why you've been downvoted. I'm interning at Mozilla right and as that design document says, GC and DOM access for WASM are very much on people's radar - they just won't make it into the initial roll-out.
- warbiscuit 10y ago
  I hope DOM access comes very close on the heels of the initial design... Javascript is an interesting language (particularly after it's recent revival), but IMO it's recent jumpstart would never have happened if it weren't for one killer feature: access to the HTML DOM. People would (and have) forgiven many other things, just for the utility of that as the presentation layer. I certainly would have picked up whatever language the browsers were pushing, where DOM access was a requirement. Conversely, I remember trying to get java applets to interact with HTML -- you have to message things through a tiny hole to/from javascript; which was (one of the many) things which made everyone hate java applets.
  - megalodon 10y ago
    I just hope that when it happens we will be able to view and read the source of WASM in the same way we can with javascript now. This is one of the foundations of WWW, please don't turn it into a closed source app store.
    - gsnedders 10y ago
      We lost that years ago with minification. Source maps can work as well for WASM as they can for minified JS.
      - kuschku 10y ago
        Then make browsers require full source maps for every website, or refuse to run them. That’d be finally a solution. Or require source maps by law. EDIT: Why the downvotes? The only way to preserve the right to modify and decompile in the long term is by creating technical or legal measures enforcing it. JS was one technical measure, so now we need alternatives.
        jfbastien 10y ago
        That would be awfully slow to transfer (or just verify) when most people never view the source map. What's a "valid" source map anyways? Furthermore, debugging with sourcemaps is suboptimal. WebAssembly wants to support much better debug information than this.
        gsnedders 10y ago
        And it'd imply you need a source map even with unminified JS. And what's to say the source map maps to non-minified JS?
        kuschku 10y ago
        It’s not about debugging, it’s about the legal "right to decompile", which is intended to give customers and companies the right to take apart products and software they bought (even from competitors), and gain knowledge from that. It’s also intended to allow them to modify it for their own purposes, and provide the modifications to others who have a license to the original product. Especially on the web this was finally possible, and now you’re suggesting to take this away again?
- supster 10y ago
  If there is no GC, could a language like Rust or Swift still target WASM?
  - steveklabnik 10y ago
    We plan on having Rust target webassembly, and there's already basic support for doing so.
    - brett40324 10y ago
      Where can I learn more about this basic support? There's the next full stack paradigm right there. I give it two years, and it will be called rustic-asm framework...
      - steveklabnik 10y ago
        https://github.com/brson/mir2wasm https://github.com/brson/mir2wasm It's still very early, and there's other avenues as well: an LLVM backend, for example.
        brett40324 10y ago
        Cool, i appreciate the link.
      - fizzbatter 10y ago
        haha :D. I also have plans for a Rust web framework. Nothing fancy, and it will likely suck, but it's a dream :)
  - PudgePacket 10y ago
    Rust doesn't use a GC, so it should be fine. Is that what you meant ?
  - DasIch 10y ago
    Languages that don't require a GC would be fine to begin with, other languages would have to implement a GC in WASM.
- supster 10y ago
  If there is no GC, could a language like Rust or Swift still target WASM?
- fizzbatter 10y ago
  DOM and GC are on the plan list thought, fwiw. It will, as far as the planning is concerned.
Millennium 10y ago
1 - You could use C# (provided that a compiler exists), but this only gets you the language, not the APIs and libraries commonly used by it. In that sense, it's not much different from using Emscripten (a compiler that goes from other LLVM languages to JavaScript) today. For example, XAML won't work unless someone writes a library to translate it into the browser's usual structures. 2 - It's still JavaScript underneath (more accurately, it's asm.js underneath).
- sp332 10y ago
  asm.js can interpret wasm as a fallback, but once wasm gets built-in to browsers, it won't be JS anymore.
  - bobajeff 10y ago
    I've read somewhere that so far the experiments for having asm.js polyfill webassembly isn't looking too promising anymore. I could be wrong though.
    - binji 10y ago
      I've made some progress on this, but there's still a way to go: https://github.com/WebAssembly/sexpr-wasm-prototype/commit/833daf9460887289d2d37ba16da56b5cda5a64af https://github.com/WebAssembly/sexpr-wasm-prototype/commit/8...
Klathmon 10y ago
WebAssembly is not a replacement for JavaScript, and (IMO) it most likely won't ever be. At the very least JavaScript will always be around as a "glue" language to use wasm binaries. I think of the relationship between JavaScript and WebAssembly as the relationship between Python and C. JavaScript will call out to a wasm binary for some "heavy lifting" and JavaScript will be used to "glue" the data to the DOM. Also like the Python-C relationship, the wasm can be a compile target for non-javascript libraries. But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. It's possible (both now and in the future), but it's always going to be a leaky abstraction, or your language will end up being similar enough to javascript that targeting wasm is largely pointless (think TypeScript or Flow).
- fizzbatter 10y ago
  > But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. The performance of touching the DOM and browser APIs will be the factor that decides that, imo. I think you may be underestimating how many people are partially or heavily disgruntled at javascript, and would happily replace it if given the chance. If speed is not an issue, and it's purely by choice of the user, i think there will be a lot of interesting changes to the web in the coming years. Hell, for many applications i'd even be willing to accept a speed loss to use "my preferred language". And, in the event that certain tasks are indeed too slow, perhaps i'll be able to pass data back and forth between my WASM and JS to let JS deal with the performance critical DOM. Regardless, i'm quite excited, and hope to see something fruitful from it.
  - bluejekyll 10y ago
    Yes. With this we can finally be less restricted in our language choice. I think the community of people who want tyoe safe languages is large, and this will the a target for them. I just hope for Dom bindings through the WASM ABI.
  - douche 10y ago
    Javascript is awful. If WebAssembly is anywhere near consistent across browsers, and there are better languages that compile to WebAssembly, I would go that way in a New York minute.
dekimir 10y ago
It's hard to speculate how the culture and philosophy of web development will change, so let's leave that aside and consider what's possible to do. It's certainly possible to compile into wasm a desktop program in a high-level language, even a program with a GUI. When the browser runs that wasm, the user will interact with your GUI instead of HTML elements. See webassembly.github.io/demo. More excitingly, I presume it will one day be possible to compile a mobile app into wasm and execute it in a browser, achieving instant parity between mobile web and apps.
- sspiff 10y ago
  The greatest disparity between mobile and native is the level of sandboxing, browser chrome and restrictions on user interactions reserved by the browser. Taking those away is not what WebAssembly does. Indeed, taking those away would be breaking the web rather than improving it...

spankalee 10y ago

WASM doesn't have access to the DOM, or a GC, or very easy interop with JavaScript, so the answer is mostly "no".

stupidcar 10y ago
All that is planned though, just not for the MVP: https://github.com/WebAssembly/design/blob/master/GC.md https://github.com/WebAssembly/design/blob/master/GC.md
- mintplant 10y ago
  No idea why you've been downvoted. I'm interning at Mozilla right and as that design document says, GC and DOM access for WASM are very much on people's radar - they just won't make it into the initial roll-out.
warbiscuit 10y ago
I hope DOM access comes very close on the heels of the initial design... Javascript is an interesting language (particularly after it's recent revival), but IMO it's recent jumpstart would never have happened if it weren't for one killer feature: access to the HTML DOM. People would (and have) forgiven many other things, just for the utility of that as the presentation layer. I certainly would have picked up whatever language the browsers were pushing, where DOM access was a requirement. Conversely, I remember trying to get java applets to interact with HTML -- you have to message things through a tiny hole to/from javascript; which was (one of the many) things which made everyone hate java applets.
- megalodon 10y ago
  I just hope that when it happens we will be able to view and read the source of WASM in the same way we can with javascript now. This is one of the foundations of WWW, please don't turn it into a closed source app store.
  - gsnedders 10y ago
    We lost that years ago with minification. Source maps can work as well for WASM as they can for minified JS.
    - kuschku 10y ago
      Then make browsers require full source maps for every website, or refuse to run them. That’d be finally a solution. Or require source maps by law. EDIT: Why the downvotes? The only way to preserve the right to modify and decompile in the long term is by creating technical or legal measures enforcing it. JS was one technical measure, so now we need alternatives.
      - jfbastien 10y ago
        That would be awfully slow to transfer (or just verify) when most people never view the source map. What's a "valid" source map anyways? Furthermore, debugging with sourcemaps is suboptimal. WebAssembly wants to support much better debug information than this.
        gsnedders 10y ago
        And it'd imply you need a source map even with unminified JS. And what's to say the source map maps to non-minified JS?
        kuschku 10y ago
        It’s not about debugging, it’s about the legal "right to decompile", which is intended to give customers and companies the right to take apart products and software they bought (even from competitors), and gain knowledge from that. It’s also intended to allow them to modify it for their own purposes, and provide the modifications to others who have a license to the original product. Especially on the web this was finally possible, and now you’re suggesting to take this away again?
supster 10y ago
If there is no GC, could a language like Rust or Swift still target WASM?
- steveklabnik 10y ago
  We plan on having Rust target webassembly, and there's already basic support for doing so.
  - brett40324 10y ago
    Where can I learn more about this basic support? There's the next full stack paradigm right there. I give it two years, and it will be called rustic-asm framework...
    - steveklabnik 10y ago
      https://github.com/brson/mir2wasm https://github.com/brson/mir2wasm It's still very early, and there's other avenues as well: an LLVM backend, for example.
      - brett40324 10y ago
        Cool, i appreciate the link.
    - fizzbatter 10y ago
      haha :D. I also have plans for a Rust web framework. Nothing fancy, and it will likely suck, but it's a dream :)
- PudgePacket 10y ago
  Rust doesn't use a GC, so it should be fine. Is that what you meant ?
- DasIch 10y ago
  Languages that don't require a GC would be fine to begin with, other languages would have to implement a GC in WASM.
supster 10y ago
If there is no GC, could a language like Rust or Swift still target WASM?
fizzbatter 10y ago
DOM and GC are on the plan list thought, fwiw. It will, as far as the planning is concerned.

Millennium 10y ago

1 - You could use C# (provided that a compiler exists), but this only gets you the language, not the APIs and libraries commonly used by it. In that sense, it's not much different from using Emscripten (a compiler that goes from other LLVM languages to JavaScript) today. For example, XAML won't work unless someone writes a library to translate it into the browser's usual structures. 2 - It's still JavaScript underneath (more accurately, it's asm.js underneath).

sp332 10y ago
asm.js can interpret wasm as a fallback, but once wasm gets built-in to browsers, it won't be JS anymore.
- bobajeff 10y ago
  I've read somewhere that so far the experiments for having asm.js polyfill webassembly isn't looking too promising anymore. I could be wrong though.
  - binji 10y ago
    I've made some progress on this, but there's still a way to go: https://github.com/WebAssembly/sexpr-wasm-prototype/commit/833daf9460887289d2d37ba16da56b5cda5a64af https://github.com/WebAssembly/sexpr-wasm-prototype/commit/8...

Klathmon 10y ago

WebAssembly is not a replacement for JavaScript, and (IMO) it most likely won't ever be. At the very least JavaScript will always be around as a "glue" language to use wasm binaries. I think of the relationship between JavaScript and WebAssembly as the relationship between Python and C. JavaScript will call out to a wasm binary for some "heavy lifting" and JavaScript will be used to "glue" the data to the DOM. Also like the Python-C relationship, the wasm can be a compile target for non-javascript libraries. But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. It's possible (both now and in the future), but it's always going to be a leaky abstraction, or your language will end up being similar enough to javascript that targeting wasm is largely pointless (think TypeScript or Flow).

fizzbatter 10y ago
> But I honestly don't see writing non-javascript web applications being mainstream any more than it is now at any point in the near-ish future. The performance of touching the DOM and browser APIs will be the factor that decides that, imo. I think you may be underestimating how many people are partially or heavily disgruntled at javascript, and would happily replace it if given the chance. If speed is not an issue, and it's purely by choice of the user, i think there will be a lot of interesting changes to the web in the coming years. Hell, for many applications i'd even be willing to accept a speed loss to use "my preferred language". And, in the event that certain tasks are indeed too slow, perhaps i'll be able to pass data back and forth between my WASM and JS to let JS deal with the performance critical DOM. Regardless, i'm quite excited, and hope to see something fruitful from it.
- bluejekyll 10y ago
  Yes. With this we can finally be less restricted in our language choice. I think the community of people who want tyoe safe languages is large, and this will the a target for them. I just hope for Dom bindings through the WASM ABI.
- douche 10y ago
  Javascript is awful. If WebAssembly is anywhere near consistent across browsers, and there are better languages that compile to WebAssembly, I would go that way in a New York minute.

dekimir 10y ago

It's hard to speculate how the culture and philosophy of web development will change, so let's leave that aside and consider what's possible to do. It's certainly possible to compile into wasm a desktop program in a high-level language, even a program with a GUI. When the browser runs that wasm, the user will interact with your GUI instead of HTML elements. See webassembly.github.io/demo. More excitingly, I presume it will one day be possible to compile a mobile app into wasm and execute it in a browser, achieving instant parity between mobile web and apps.

sspiff 10y ago
The greatest disparity between mobile and native is the level of sandboxing, browser chrome and restrictions on user interactions reserved by the browser. Taking those away is not what WebAssembly does. Indeed, taking those away would be breaking the web rather than improving it...