Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide own JS code to load and instantiate the WASM file #689

Closed
LukasKalbertodt opened this issue Aug 12, 2018 · 4 comments
Closed

Provide own JS code to load and instantiate the WASM file #689

LukasKalbertodt opened this issue Aug 12, 2018 · 4 comments

Comments

@LukasKalbertodt
Copy link

Hi there!

I've been playing with wasm-bindgen for some time now and I think I'm missing a feature. Please note that I don't have any previous experience with NPM and webpack as well as very little experience in JS. So I might just have missed something.

Anyway, as I understand it there are basically three different ways to generate the JS shim:

  • normal:
    • Uses ES6 export statements to make the file a valid ES6 module
    • Uses import * as wasm from './foo_bg' to import WASM file. As far as I understand it, this only works together with some loader/package-thingy such as webpack. Browser can't load wasm modules via import statements yet, right?
  • nodejs
    • Uses module.exports.bar = ... (a node-style module)
    • Reads the WASM file via require('fs').readFileSync() and instantiates it manually
  • no-modules
    • uses a function thingy as module
    • Loads WASM file via fetch and instantiates manually

So I want to use the WASM file via the network (nodejs is out) and I also don't want to use something like webpack (so normal is out, right?). I'm left with no-modules, BUT I'd like to do the loading and instantiating myself!

Instantiating can be as simple as fetch() plus WebAssembly.instantiate(). As far as I see it, the only thing I need is (a) the path to the wasm file and (b) the export object defining all imports exports (the thing we pass to WASM.instantiate().

I think it would be great if wasm-bindgen let us define our own loading code. I see two possibility:

  • Giving the code to wasm-bindgen via --loader-code loader.js for example, or
  • Exposing the exports object from the generated shim. I think this is already happening, because I think I could just access wasm_bindgen.__exports, but I don't think it's intended that way, right?

Additionally, I would like to write my own loader + have a valid ES6 module. So I would like to have a way to configure how importing the wasm file is done in normal mode, too.


So: is this a good idea? Is this something other people want as well? Am I just missing something? Thanks :)

@alexcrichton
Copy link
Contributor

Thanks for the report! It really is a bumer that wasm modules aren't supported as native ES modules yet, it does indeed add all sorts of pain like this!

One thing I might recommend for this use case though is a tool like wasm2es6js in this repository. You can use that to translate a wasm module to an ES module (sort of) and perhaps something like that could be used in your use case?

I'm not sure how we'd best deal with foreign instantiation of the wasm module itself, so it may be one where we don't have a great way to insert that into the generated JS here but using a custom tool locally could work!

@alexcrichton
Copy link
Contributor

With #969 we now have the option via --no-modules to pass in an already-compiled WebAssembly.Module if necessary, and for ES modules this is largely up to bundlers and such. As a result I'm gonna go ahead and close this for now, but we can always come back to it as situations arise!

@TitanThinktank
Copy link

@LukasKalbertodt did you succeed in doing that with first option ?

@LukasKalbertodt
Copy link
Author

@TitanThinktank Not yet. I hadn't had time to play with WASM recently. But I plan on using wasm and wasm-bindgen in a project within the next couple of months. So if it's still relevant by then, I can post my experience regarding this issue here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants