5 ms·

Maybe I just can't find it, but the largest blocker for using Rust on the web for me is a lack of a exposure/binding system (like embind). I'm not particularly

Maybe I just can't find it, but the largest blocker for using Rust on the web for me is a lack of a exposure/binding system (like embind). I'm not particularly interested in writing entire webapps in Rust but I do see it being useful for smaller self-contained modules inside a larger JS app. Not having a robust binding API makes that difficult. EDIT: But unrelated criticisms aside, congrats on the progress! I'm excited to see more first class support of WASM from languages other than C/C++.

arbie 9y ago
I am excited for WASM for the same reason; not for wholesale migration, but targeted optimization. Hope documentation for this (likely very popular use-case) improves as WASM matures.
- cormacrelf 9y ago
  Can anyone describe the (overhead) cost of calling into WASM code in the implementations so far? A lot of optimize-able areas are things like RxJS or Promise implementations (eg Bluebird), or generally libraries making the stack trace like [userspace code] -> [library code, approx 20 stack frames] -> [more userspace]. Should we think of the WASM-JS bridge cost like system calls, or like inline assembly?
  - skybrian 9y ago
    You need to look at serialization overhead for exchanging data. For example, I don't think web assembly has direct access to JavaScript strings? What about JSON? Seems like you're either converting a lot of strings (which wastes memory) or calling lots of JavaScript string methods from web assembly, which is not likely to be fast in an inner loop.
    - cormacrelf 9y ago
      To be clear, I haven't done anything serious in WASM that would hit any limits here.
  - josephg 9y ago
    I'm curious about this too. I hand-wrote a perlin noise generation function in asmjs when that was the future. Then I called my noise function from a loop in javascript to paint an image (1 call per pixel - about 1M calls). Running the perlin noise code with the asmjs engine in Firefox turned out to be a bit slower than running all the code through FF's regular javascript engine. The asmjs code ran fast, but the FFI overhead at the boundary between JS and asmjs made the system slower overall. Given how easy it looks, I might try the same experiment with Rust & WASM to see where we're at. That said, this is the sort of thing which can definitely be improved over time.
    - Crespyl 9y ago
      These days it's probably possible to use a buffer in the asmjs/WASM side and generate the image data there, only exporting back to the JS side after the job is complete. That should significantly cut down on the overhead.
  - Matthias247 9y ago
    I guess it will depend heavily on the type of your exchanged parameters. If it's a few integers then it's no problem since both JS and the WASM side can easily read those. However for complex objects (like Javascript objects, strings or DOM objects) objects you need a serialization mechanism for those. That might be similar to what typical system call implementations do. However system calls mostly have a very simply set of parameters, so transferring Javascript objects might be far worse. If you would want to share Javascript objects on both sides you would also need some kind of reference-counted handles, which can identify the objects. I haven't done anything with WASM yet, but I'm pretty sure the domains you mentioned (promises, asynchronous programming and also DOM handling) are the ones which will least likely benefit from WASM. Lower level math algorithms might however benefit a lot.
themihai 9y ago
I think the real issue is the lack of DOM access rather than binding to JS.
- tyingq 9y ago
  Supposedly they are adding things like polymorphic inline cache, garbage collection, threads, etc, that would make it more like a VM. Perhaps enough that Python, PHP, Ruby, or similar languages could run in WASM without downloading the whole runtime. That plus native DOM access might make the front end web as diverse as the back end web. I'm curious whether the fragmentation that would bring on is a net add, or a net drain on the web as a whole.
  - themihai 9y ago
    I wouldn't say that fragmentation on the backend is a net drain as a whole...
- ralfn 9y ago
  Isn't the point of the whole architecture that from a security perspective all IO will always be through JavaScript. Replicating the attack surface of the browser in JavaScript land in WebAssembly land goes against the whole design of it. It's for the community to make nice libraries that expose the browser features to WebAssembly land in JavaScript. It's also the right place to deal with cross browser differences.
  - themihai 9y ago
    Well the IO is ultimately handled/sandboxed by the browser not by JavaScript so as far as security is concerned JavaScript and WASM should have the same access to IO/Web APIs. I think the attack surface you are talking about is really a implementation detail and browsers could use a common middleware that both JavaScript and WASM can use. In a distant future I would see JavaScript actually compiled to WASM(maybe the browser would pipe it directly into a WASM compiler before to execute it) to reduce the maintenance costs and perhaps also the attack surface you are talking about. The whole point of WASM was to cut off the middle man (i.e. JavaScript) so that we can reach native-like performance. WASM should be the ultimate dominator not JavaScript. >> It's for the community to make nice libraries that expose the browser features to WebAssembly land in JavaScript. It's also the right place to deal with cross browser differences. I believe the community could make nice libraries compiled to WASM that anyone can use regardless of the programming language. JavaScript would be just another language(albeit a popular one, at least due legacy reasons).
kenOfYugen 9y ago
What do you mean by 'first class support' of WASM in C/C++? Is it somehow possible to produce wasm binaries without utilizing emscripten?
- RX14 9y ago
  Yes, llvm has built in wasm support for a while now.
  - steveklabnik 9y ago
    Incidentally, that's how this target works in Rust; we also have an emscripten-based target.
  - buu700 9y ago
    The plan for emscripten is actually to replace its own wasm compiler with LLVM, and possibly drop its asm.js compiler in favor of running wasm2asm on LLVM's wasm output: https://github.com/kripken/emscripten/issues/5827 https://github.com/kripken/emscripten/issues/5827 Aside from keeping emscripten's code smaller / more maintainable and allowing the team to focus more on its role as high-level tooling, this should improve the size and performance of emscripten output since IIRC it's currently missing out on a lot of optimization opportunity by producing wasm as transpiled asm.js.
    - azakai 9y ago
      > IIRC it's currently missing out on a lot of optimization opportunity by producing wasm as transpiled asm.js. That's actually not true: the asm.js => wasm path emits better code (smaller, faster) than the wasm backend path currently. However, the wasm backend path is being improved, and should eventually get to parity.
      - buu700 9y ago
        Ah okay, interesting. Is it because wasm doesn't yet add any new functionality over asm.js that using asm.js as an intermediary step isn't inherently worse? In that case, it sounds like the LLVM backend will only yield clear user-facing benefits when new features like pthreads are introduced?
steveklabnik 9y ago
I agree that the best use-case here isn't full apps in Rust, but writing high-performance modules. The webpack team is working on stuff so you can just drop a rust file into your proejct, and it will do everything needed for super easy integration. https://crates.io/crates/stdweb https://crates.io/crates/stdweb sort of gives you the bindings you want, by the way.

arbie 9y ago

I am excited for WASM for the same reason; not for wholesale migration, but targeted optimization. Hope documentation for this (likely very popular use-case) improves as WASM matures.

cormacrelf 9y ago
Can anyone describe the (overhead) cost of calling into WASM code in the implementations so far? A lot of optimize-able areas are things like RxJS or Promise implementations (eg Bluebird), or generally libraries making the stack trace like [userspace code] -> [library code, approx 20 stack frames] -> [more userspace]. Should we think of the WASM-JS bridge cost like system calls, or like inline assembly?
- skybrian 9y ago
  You need to look at serialization overhead for exchanging data. For example, I don't think web assembly has direct access to JavaScript strings? What about JSON? Seems like you're either converting a lot of strings (which wastes memory) or calling lots of JavaScript string methods from web assembly, which is not likely to be fast in an inner loop.
  - cormacrelf 9y ago
    To be clear, I haven't done anything serious in WASM that would hit any limits here.
- josephg 9y ago
  I'm curious about this too. I hand-wrote a perlin noise generation function in asmjs when that was the future. Then I called my noise function from a loop in javascript to paint an image (1 call per pixel - about 1M calls). Running the perlin noise code with the asmjs engine in Firefox turned out to be a bit slower than running all the code through FF's regular javascript engine. The asmjs code ran fast, but the FFI overhead at the boundary between JS and asmjs made the system slower overall. Given how easy it looks, I might try the same experiment with Rust & WASM to see where we're at. That said, this is the sort of thing which can definitely be improved over time.
  - Crespyl 9y ago
    These days it's probably possible to use a buffer in the asmjs/WASM side and generate the image data there, only exporting back to the JS side after the job is complete. That should significantly cut down on the overhead.
- Matthias247 9y ago
  I guess it will depend heavily on the type of your exchanged parameters. If it's a few integers then it's no problem since both JS and the WASM side can easily read those. However for complex objects (like Javascript objects, strings or DOM objects) objects you need a serialization mechanism for those. That might be similar to what typical system call implementations do. However system calls mostly have a very simply set of parameters, so transferring Javascript objects might be far worse. If you would want to share Javascript objects on both sides you would also need some kind of reference-counted handles, which can identify the objects. I haven't done anything with WASM yet, but I'm pretty sure the domains you mentioned (promises, asynchronous programming and also DOM handling) are the ones which will least likely benefit from WASM. Lower level math algorithms might however benefit a lot.

themihai 9y ago

I think the real issue is the lack of DOM access rather than binding to JS.

tyingq 9y ago
Supposedly they are adding things like polymorphic inline cache, garbage collection, threads, etc, that would make it more like a VM. Perhaps enough that Python, PHP, Ruby, or similar languages could run in WASM without downloading the whole runtime. That plus native DOM access might make the front end web as diverse as the back end web. I'm curious whether the fragmentation that would bring on is a net add, or a net drain on the web as a whole.
- themihai 9y ago
  I wouldn't say that fragmentation on the backend is a net drain as a whole...
ralfn 9y ago
Isn't the point of the whole architecture that from a security perspective all IO will always be through JavaScript. Replicating the attack surface of the browser in JavaScript land in WebAssembly land goes against the whole design of it. It's for the community to make nice libraries that expose the browser features to WebAssembly land in JavaScript. It's also the right place to deal with cross browser differences.
- themihai 9y ago
  Well the IO is ultimately handled/sandboxed by the browser not by JavaScript so as far as security is concerned JavaScript and WASM should have the same access to IO/Web APIs. I think the attack surface you are talking about is really a implementation detail and browsers could use a common middleware that both JavaScript and WASM can use. In a distant future I would see JavaScript actually compiled to WASM(maybe the browser would pipe it directly into a WASM compiler before to execute it) to reduce the maintenance costs and perhaps also the attack surface you are talking about. The whole point of WASM was to cut off the middle man (i.e. JavaScript) so that we can reach native-like performance. WASM should be the ultimate dominator not JavaScript. >> It's for the community to make nice libraries that expose the browser features to WebAssembly land in JavaScript. It's also the right place to deal with cross browser differences. I believe the community could make nice libraries compiled to WASM that anyone can use regardless of the programming language. JavaScript would be just another language(albeit a popular one, at least due legacy reasons).

kenOfYugen 9y ago

What do you mean by 'first class support' of WASM in C/C++? Is it somehow possible to produce wasm binaries without utilizing emscripten?

RX14 9y ago
Yes, llvm has built in wasm support for a while now.
- steveklabnik 9y ago
  Incidentally, that's how this target works in Rust; we also have an emscripten-based target.
- buu700 9y ago
  The plan for emscripten is actually to replace its own wasm compiler with LLVM, and possibly drop its asm.js compiler in favor of running wasm2asm on LLVM's wasm output: https://github.com/kripken/emscripten/issues/5827 https://github.com/kripken/emscripten/issues/5827 Aside from keeping emscripten's code smaller / more maintainable and allowing the team to focus more on its role as high-level tooling, this should improve the size and performance of emscripten output since IIRC it's currently missing out on a lot of optimization opportunity by producing wasm as transpiled asm.js.
  - azakai 9y ago
    > IIRC it's currently missing out on a lot of optimization opportunity by producing wasm as transpiled asm.js. That's actually not true: the asm.js => wasm path emits better code (smaller, faster) than the wasm backend path currently. However, the wasm backend path is being improved, and should eventually get to parity.
    - buu700 9y ago
      Ah okay, interesting. Is it because wasm doesn't yet add any new functionality over asm.js that using asm.js as an intermediary step isn't inherently worse? In that case, it sounds like the LLVM backend will only yield clear user-facing benefits when new features like pthreads are introduced?

steveklabnik 9y ago

I agree that the best use-case here isn't full apps in Rust, but writing high-performance modules. The webpack team is working on stuff so you can just drop a rust file into your proejct, and it will do everything needed for super easy integration. https://crates.io/crates/stdweb https://crates.io/crates/stdweb sort of gives you the bindings you want, by the way.