What do I need to know if I intend to use a crate in a WASM context

WASM is becoming more and more a desired compilation target for me. But it's not like the others where in most cases you can just expect your code to work.

Unfortunately this means I may still prefer to just look for JS libs and do all my work in JavaScript, unless I can know one way or another which crates will be functional in a WASM context.

This has to be a common problem, so short of attaining a deep understanding of WASM and applying it manually to every crate i come across, are there any tools or resources or tricks?

Thanks!

3 Likes

Here's the ways I tell if a crate is WASM compatible myself, in order of difficulty:

  1. Check the docs real quick and see if they say anything about WASM support
  2. Check the CI on the git repo to see if the build or test on WASM
  3. Clone the crate and run cargo build --target wasm32-unknown-uknown and see if it compiles
  4. If step 3 worked, then try out a minimal example and see if I can get it working in the browser

As a general rule, a lot of crates do just work in WASM, as long as they don't require access to the system. For instance async-io isn't going to work in WASM because it's designed to talk to system interfaces to provide IO. Other gotchas can be random number generation, but there's crates for that and often you just need to add a dependency to your crate with the right feature to make it work.

Oh, yeah, and multi-threading doesn't work on WASM like it does on native. It can work, but it's super difficult to do on web so anything that requires multi-threading to work at all will not work right on WASM.

Somewhat related question: are you wanting to use Rust inside of a JavaScript application, or is your app already completely written in Rust?

3 Likes

Thank you. Those are some good tips. I wonder if the process could be automated someway so that crates.io could list compatibility for us.

Here's a common use case. I often want to bring to WASM some bit of code that processes a file.

The problem is, most libraries typically provide their own way of grabbing the file (which is usually involved std::fs and thus is no go on WASM... If the lib doesn't offer an alternative way (i.e from_bytes) should that be considered bad design and therefore a PR will probably be welcome?

Sorry if this a little bit of a dumb post. :slight_smile:

To respond to your question, I'm often just looking to do a bit of client side processing, and when the task is reasonably complex i prefer to code it in my favourite language

1 Like

I suppose docs.rs or crates.io could find out whether or not a crate builds on WASM, but at the same time that often requires different features and they wouldn't know which feature combination to use. And even if it does build on WASM, it doesn't necessarily mean that it works. Lots of the standard library will panic if used on WASM, even though it will compile.

I haven't thought it through enough, but it seems like the best technique to help this situation would be to give some standardized, easy way to let crate authors indicate their WASM compatibility in a way that crates.io could read.

I guess it's somewhat similar to the #[no_std] tag that gets added to nno_std crates.

Another thought, we do already have a #wasm keyword on crates.io. Maybe we just start an initiative to start tagging WASM compatible crates with that keyword. :man_shrugging: Just some ideas. :slight_smile:

Ah, yeah, that makes sense.

I'd think that if there were no other outstanding reasons that the library couldn't work on WASM that a PR would be welcome. At least I would like it if it were my crate!

It would make sense as a default feature that could be disabled to make it work on WASM.

Not at all. :slight_smile:

Definitely. I haven't run into a use-case for it yet, because most of my processing tends to be server side, but I would do the same thing.

I'd suggest introducing a function that takes a generic Read rather than a from_bytes, but I'd certainly hope that crate authors would be delighted with a pull request that removes a requirement that contents be found on the filesystem.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.