3 ms·

WebAssembly lets people write in C++, Ruby, Python, etc and for that code to work in the browser like Javascript does at the moment. Am I correct?

by eecks 11y ago

purplerabbit 11y ago
Yes, that's correct.
- jokoon 11y ago
  What about opengl and hardware inputs for instance? What kind of standard libraries will be available ?
  - kevingadd 11y ago
    WebAssembly will (with a few small exceptions) use existing web APIs.
Klathmon 11y ago
Yes, but it is a very limited subset of the whole "web ecosystem". In its first version, it will not be able to access any/most web APIs directly (so you won't be writing a web app in 100% C++ any time soon). The goal is to allow "Computationally intensive" bits of code to be compiled, while leaving JS to act as the glue for it all.
azakai 11y ago
Mostly. The initial target is C++ and similar languages, and it will not have DOM access, but using suitable libraries (libc, SDL, etc., for example emscripten's) you can write a normal C++ program and have it run in the browser. You can also run Ruby and Python in the browser by just compiling their C or C++ VMs. But that won't still work "like JavaScript" - their objects won't be native VM objects in the browser, it won't use the browser's GC, they won't be observable in the browser's debugger, etc. So far all of that was already possible, and done, with asm.js. In the future, it is a goal to work to do GC object integration, so that something like Ruby or Python could actually compile down to something with native VM objects, and that would also allow calling DOM APIs directly. (This will likely still require a compiled VM, though.)
- eecks 11y ago
  Thanks for the explanation
- discreteevent 11y ago
  Its worth pointing out that it would hardly be practical to expect users to download the code for the entire Ruby VM (and libraries) when they visit your web page.
  - Eridrus 11y ago
    Depends how you look at it. If you're using a web page that is mostly just a CRUD app, sure, no-one will wait around for that, but if you're shipping a version of IPython that can run in the browser, I think people would be pretty happy about it as long as the blob can be cached and hopefully shared between sites since it's on a shared CDN.
    - azakai 11y ago
      I think you're right. While downloading a VM doesn't make sense for a small site, for many cases it could. There are also fairly compact VMs for some languages. And WebAssembly will make the VM download substantially smaller.
  - natrius 11y ago
    Caching is hard because we serve the same code from so many different servers. IPFS fixes that by referring to files by a hash of their content. Commonly used binaries will be cached on your browser, and every app will refer to them the same way.

WebAssembly lets people write in C++, Ruby, Python, etc and for that code to work in the browser like Javascript does at the moment. Am I correct?

by eecks 11y ago

WebAssembly lets people write in C++, Ruby, Python, etc and for that code to work in the browser like Javascript does at the moment. Am I correct?

purplerabbit 11y ago

Yes, that's correct.

jokoon 11y ago
What about opengl and hardware inputs for instance? What kind of standard libraries will be available ?
- kevingadd 11y ago
  WebAssembly will (with a few small exceptions) use existing web APIs.

Klathmon 11y ago

Yes, but it is a very limited subset of the whole "web ecosystem". In its first version, it will not be able to access any/most web APIs directly (so you won't be writing a web app in 100% C++ any time soon). The goal is to allow "Computationally intensive" bits of code to be compiled, while leaving JS to act as the glue for it all.

azakai 11y ago

Mostly. The initial target is C++ and similar languages, and it will not have DOM access, but using suitable libraries (libc, SDL, etc., for example emscripten's) you can write a normal C++ program and have it run in the browser. You can also run Ruby and Python in the browser by just compiling their C or C++ VMs. But that won't still work "like JavaScript" - their objects won't be native VM objects in the browser, it won't use the browser's GC, they won't be observable in the browser's debugger, etc. So far all of that was already possible, and done, with asm.js. In the future, it is a goal to work to do GC object integration, so that something like Ruby or Python could actually compile down to something with native VM objects, and that would also allow calling DOM APIs directly. (This will likely still require a compiled VM, though.)

eecks 11y ago
Thanks for the explanation
discreteevent 11y ago
Its worth pointing out that it would hardly be practical to expect users to download the code for the entire Ruby VM (and libraries) when they visit your web page.
- Eridrus 11y ago
  Depends how you look at it. If you're using a web page that is mostly just a CRUD app, sure, no-one will wait around for that, but if you're shipping a version of IPython that can run in the browser, I think people would be pretty happy about it as long as the blob can be cached and hopefully shared between sites since it's on a shared CDN.
  - azakai 11y ago
    I think you're right. While downloading a VM doesn't make sense for a small site, for many cases it could. There are also fairly compact VMs for some languages. And WebAssembly will make the VM download substantially smaller.
- natrius 11y ago
  Caching is hard because we serve the same code from so many different servers. IPFS fixes that by referring to files by a hash of their content. Commonly used binaries will be cached on your browser, and every app will refer to them the same way.