Use Asyncify to handle synchronous commands? about wasmer-js HOT 6 CLOSED

Perhaps https://github.com/GoogleChromeLabs/asyncify could be useful for this!

from wasmer-js.

Cc @kripken for the performance issues. It’s unfortunate that Binaryen is too slow here because this is definitely the type of use case we want to support!

from wasmer-js.

Yo! What up Thomas? 😄

So at the last WasmSf, this is what I tried to ask about without announcing this haha! 😄

So we tried running Binaryen.js to run a bunch of passes for us, but since it builds an AST and then makes changes, and then get output from that AST, it was super slow for desktop devices, and even slower on mobile. Since we wanted to make sure this would be reasonably fast on many devices we decided to keep an eye on Asyncify for the future, and we discussed it may be a good idea for us to try and do this server side on WAPM and/or detect if a module is already asyncified 😄

So it's something we definitely need to do some more discussion about, but I very much appreciate you suggesting this! 😄 👍

from wasmer-js.

Oh, yeah, I was talking to @torch2424 about this earlier. Currently binaryen.js is not wasm (asm.js for maximum portability), and uses C++ exceptions. Once we have exceptions in wasm, we can make a wasm build, and that should be much faster.

Btw, one thing I didn't get - why is this done on the client?

from wasmer-js.

@tlively Yeah it is! But it's not the fault of binaryen at all, what we are trying to do is a little extreme haha! 😂

@kripken Yep! Looking forwawrd to it! 😄 And the reason why we wanted to do it on the client, as we wanted anyone to use whatever module they wanted, not just modules from WAPM. So this is something we could enable for WAPM modules, but then users would have to host their own asyncify servers for their eventual end users, or pre-lower all of their modules before using them. Which I think is a little out of scope of what we wanted to achieve in our MVP. But we definitely want to be able to identify and supported asyncified modules in the future 👍

from wasmer-js.

This is no longer necessary because the new SDK executes blocking operations (like executing WebAssembly code) on a Web Worker in the background.

from wasmer-js.