8 ms·

This is one of the logical next steps towards mass WASM-adoption. Another was Cloudflare's Isolates [1]. There needs to be official OS support from vendors (Ma

by plq 8y ago

This is one of the logical next steps towards mass WASM-adoption. Another was Cloudflare's Isolates [1]. There needs to be official OS support from vendors (MacOS, Windows and Linux distros) in order to avoid the stinking pile of non-shared shared library mess that is electron. [1]: https://blog.cloudflare.com/cloud-computing-without-containers/ https://blog.cloudflare.com/cloud-computing-without-containe...

manigandham 8y ago
Mass adoption in what way?
jacobush 8y ago
So, we are officially campaigning for Javascript as the default language for everything now? :-(
- degurechaff 8y ago
  WASM is not javascript
  - AnIdiotOnTheNet 8y ago
    Funny, I hear often that "WASM is just javascript" whenever I compare it to Flash and Java, as a defense for why it is different this time and totally won't have any of the problems of those other runtimes.
    - afiori 8y ago
      Because wasm runs on the same javascript and not as a separate plugin. It will be a major feature of the browser and be automatically updated with it. (also it allows for feature discovery) It has no relation to ecmascript, but you could say that it is integrated in (but independent from) javascript. People say that it is not javascript because you can use ALL of the wasm toolchain without any trace of javascript.
    - CyberDildonics 8y ago
      WASM and javascript are run using the same underlying environment. WASM is not javascript on a language level.
- baq 8y ago
  actually, the exact opposite
  - tyfon 8y ago
    This is Java 2.0 isn't it? "Write once, run everywhere". I wonder how one would solve linking to native libraries and the like through this. I still prefer just having the application source code available so one can compile it for a specific system.
    - austincheney 8y ago
      No. Java is a language. WASM is a byte code compile target. A better comparison would be the JVM, such as a language like Scala that is definitely not Java still compiles to the JVM and can run anywhere there is a JVM. > I wonder how one would solve linking to native libraries Either use WASM outside the browser (I don't even know if that's a thing) or create some sort of import mechanism using JavaScript.
      - cyphar 8y ago
        > No. Java is a language [...] A better comparison would be the JVM I think the point was that it's a reinvention of "write once run everywhere", which had its own problems at the time (such as native libraries). Java introduced the idea, and arguing the fact that the JVM is the reason why it works is a touch pedantic in this discussion. > Either use WASM outside the browser (I don't even know if that's a thing) That's what TFA is doing.
        andrewshadura 8y ago
        Actually, Oberon first came with it, with JIT compilation of intermediate code into the target code.
        pjmlp 8y ago
        The concept goes back all the way to Xerox PARC workstations and Pascal UCSD.
- thefounder 8y ago
  This is supposed to kill javascript(hopefully)
  - austincheney 8y ago
    WASM is a parallel technology with no intention of impacting JavaScript, according to its spec. Therefore WASM will never replace JavaScript. JavaScript can be replaced, but it won't be WASM that does so. https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript https://webassembly.org/docs/faq/#is-webassembly-trying-to-r... https://webassembly.org/docs/js/ https://webassembly.org/docs/js/
    - rkangel 8y ago
      This may not be a goal of the project, but it is still the hope of a lot of people. When parity with JS is reached in terms of ability to access the DOM and JS interop, then there shouldn't be much advantage to JS, and possibly a performance penalty. Having one language in a 'privileged' position for a platform isn't ideal. At least with the mobile platforms ObjC could be supplanted by Swift, and Java by Kotlin.
      - austincheney 8y ago
        > This may not be a goal of the project, but it is still the hope of a lot of people. I hope for world peace. > When parity with JS is reached in terms of ability to access the DOM and JS interop There is work being down on DOM interop, but its not what clueless people think it is. DOM interop allows JavaScript interaction to WASM via the DOM. It doesn't allow WASM to creep out of its sandbox to become some magical JavaScript replacement. Even if it did, you would still have to learn to access the DOM. Most developers completely fail at this point. Somehow the DOM is scary. > Having one language in a 'privileged' position for a platform isn't ideal. Why not?
        pedrocr 8y ago
        These threads always repeat themselves. There are the people painfully explaining why they would like to be able to program for the web in the languages they like. And then there are the JS advocates that take it personally and go out of their way to explain why JS is all you need. Even though no other platform forces you into a single language somehow the web is different.
syrusakbary 8y ago
We are working towards that. There are two ABIs (sets of syscalls, such as read a file or opening a socket) that we believe would help to bring universality between platforms: * CloudABI * PWSIX We wrote more about it here: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9 https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9
- plq 8y ago
  What about packaging & distribution? Unless I missed something, it's up to us to package & ship our app complete with assets. I firmly believe that this project is incomplete without a standard like .war (Web ARchive, from the Java ecosystem). Of course, you could just use what's out there eg. .app (macos) or .appimage (gnu/linux) but there has to be a well-defined and clearly endorsed way of distributing wasmer'd apps.
  - tyfon 8y ago
    This "ship all libraries in the package" approach is also quite scary, you never know if an app will use your patched local libraries or use an ancient library with lots of exploits. Double so for anything exposed to the internet.
    - plq 8y ago
      WASM binaries needn't be exposed to the internet. That said, the OS-sanctioned runtime could very well support a shared-object-like approach instead of one-binary-per-app but that would 1. complicate the runtime quite a lot 2. hinder startup times of wasm apps due to dependency solving.
steveklabnik 8y ago
Small nit, the product is Cloudflare Workers. https://workers.dev/ https://workers.dev/ Isolates are a V8 feature that is used to implement Workers: https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...

by plq 8y ago

manigandham 8y ago

Mass adoption in what way?

jacobush 8y ago

So, we are officially campaigning for Javascript as the default language for everything now? :-(

degurechaff 8y ago
WASM is not javascript
- AnIdiotOnTheNet 8y ago
  Funny, I hear often that "WASM is just javascript" whenever I compare it to Flash and Java, as a defense for why it is different this time and totally won't have any of the problems of those other runtimes.
  - afiori 8y ago
    Because wasm runs on the same javascript and not as a separate plugin. It will be a major feature of the browser and be automatically updated with it. (also it allows for feature discovery) It has no relation to ecmascript, but you could say that it is integrated in (but independent from) javascript. People say that it is not javascript because you can use ALL of the wasm toolchain without any trace of javascript.
  - CyberDildonics 8y ago
    WASM and javascript are run using the same underlying environment. WASM is not javascript on a language level.
baq 8y ago
actually, the exact opposite
- tyfon 8y ago
  This is Java 2.0 isn't it? "Write once, run everywhere". I wonder how one would solve linking to native libraries and the like through this. I still prefer just having the application source code available so one can compile it for a specific system.
  - austincheney 8y ago
    No. Java is a language. WASM is a byte code compile target. A better comparison would be the JVM, such as a language like Scala that is definitely not Java still compiles to the JVM and can run anywhere there is a JVM. > I wonder how one would solve linking to native libraries Either use WASM outside the browser (I don't even know if that's a thing) or create some sort of import mechanism using JavaScript.
    - cyphar 8y ago
      > No. Java is a language [...] A better comparison would be the JVM I think the point was that it's a reinvention of "write once run everywhere", which had its own problems at the time (such as native libraries). Java introduced the idea, and arguing the fact that the JVM is the reason why it works is a touch pedantic in this discussion. > Either use WASM outside the browser (I don't even know if that's a thing) That's what TFA is doing.
      - andrewshadura 8y ago
        Actually, Oberon first came with it, with JIT compilation of intermediate code into the target code.
        pjmlp 8y ago
        The concept goes back all the way to Xerox PARC workstations and Pascal UCSD.
thefounder 8y ago
This is supposed to kill javascript(hopefully)
- austincheney 8y ago
  WASM is a parallel technology with no intention of impacting JavaScript, according to its spec. Therefore WASM will never replace JavaScript. JavaScript can be replaced, but it won't be WASM that does so. https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript https://webassembly.org/docs/faq/#is-webassembly-trying-to-r... https://webassembly.org/docs/js/ https://webassembly.org/docs/js/
  - rkangel 8y ago
    This may not be a goal of the project, but it is still the hope of a lot of people. When parity with JS is reached in terms of ability to access the DOM and JS interop, then there shouldn't be much advantage to JS, and possibly a performance penalty. Having one language in a 'privileged' position for a platform isn't ideal. At least with the mobile platforms ObjC could be supplanted by Swift, and Java by Kotlin.
    - austincheney 8y ago
      > This may not be a goal of the project, but it is still the hope of a lot of people. I hope for world peace. > When parity with JS is reached in terms of ability to access the DOM and JS interop There is work being down on DOM interop, but its not what clueless people think it is. DOM interop allows JavaScript interaction to WASM via the DOM. It doesn't allow WASM to creep out of its sandbox to become some magical JavaScript replacement. Even if it did, you would still have to learn to access the DOM. Most developers completely fail at this point. Somehow the DOM is scary. > Having one language in a 'privileged' position for a platform isn't ideal. Why not?
      - pedrocr 8y ago
        These threads always repeat themselves. There are the people painfully explaining why they would like to be able to program for the web in the languages they like. And then there are the JS advocates that take it personally and go out of their way to explain why JS is all you need. Even though no other platform forces you into a single language somehow the web is different.

syrusakbary 8y ago

We are working towards that. There are two ABIs (sets of syscalls, such as read a file or opening a socket) that we believe would help to bring universality between platforms: * CloudABI * PWSIX We wrote more about it here: https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9 https://medium.com/wasmer/webassembly-cloudabi-b573047fd0a9

plq 8y ago
What about packaging & distribution? Unless I missed something, it's up to us to package & ship our app complete with assets. I firmly believe that this project is incomplete without a standard like .war (Web ARchive, from the Java ecosystem). Of course, you could just use what's out there eg. .app (macos) or .appimage (gnu/linux) but there has to be a well-defined and clearly endorsed way of distributing wasmer'd apps.
- tyfon 8y ago
  This "ship all libraries in the package" approach is also quite scary, you never know if an app will use your patched local libraries or use an ancient library with lots of exploits. Double so for anything exposed to the internet.
  - plq 8y ago
    WASM binaries needn't be exposed to the internet. That said, the OS-sanctioned runtime could very well support a shared-object-like approach instead of one-binary-per-app but that would 1. complicate the runtime quite a lot 2. hinder startup times of wasm apps due to dependency solving.

steveklabnik 8y ago

Small nit, the product is Cloudflare Workers. https://workers.dev/ https://workers.dev/ Isolates are a V8 feature that is used to implement Workers: https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_isolate.html https://v8docs.nodesource.com/node-0.8/d5/dda/classv8_1_1_is...