Repository navigation
Consider using web_sys and unifying wasm32-unknown-unknown targets #63
Description
Activity
If stdweb does not give any advantage over wasm-bindgen, and if it can't lead to less deps being pulled in, this would greatly simplify issues downstream... I mean to just get the random data out of wasm-bindgen without features.
I am strongly against making
wasm-bindgenenabled by default forwasm32-unknown-unknown. As I wrote several times, this target can not make any assumptions about a target on which it will be executed. It can be a browser, Node.JS, smart-contract, game module system and who knows what else. If we want to simplify WASM builds for browsers/Node.JS, let's push for dedicated targets instead.Reacted by TitanThinktank, mosh and Christopher Serr@newpavlov Does setting
stdwebwork on these other platforms?Or are you just thinking other features like
wasm-bindgenandstdwebwill maybe be added later? Or do these targets just need to usedummyand they are not supported?@najamelan
We don't have those hypothetical new targets yet, so it's hard to tell ifstdwebwill work on them. IIRC it can work on other existing WASM/asm.js targets, but we don't use it on them. Don't forget that people usewasm32-unknown-unknownoutside of browsers, and even on browsers not everyone useswasm-bindgenin their build pipeline.Ideally I would like to drop feature-gated support for
wasm32-unknown-unknownaltogether, but I think it will have to wait until #4 and #21 gets properly solved.Reacted by TitanThinktank@newpavlov both our
wasm-bindgenandstdwebimpls support both browsers and Node.js, with run-time failure on other platforms. IMO this is about as good as is possible for the inspecificwasm32-unknown-unknowntarget. These impls can potentially be extended to support other interfaces — though likely smart contracts and game modules would either use one of the same interfaces or not support randomness at all. So I don't buy your argument.Of course I agree that ideally more specific targets will replace the
unknown.@dhardy
Yes,wasm32-unknown-unknownis PITA right now for us and our users. (Overall I think that making it anstdtarget was probably a mistake, motivated by a short-term goals...) But I don't think we should make conceptually wrong compromises (otherwise why shouldn't we support some popular RNG perfirial for embedded ARM targets?). Instead, in my opinion, we should use this pain to motivate Rust improvements.Yes, this approach is more painful and less convenient in a short-term, but should be more beneficial in a longer term.
Thanks for the clarification @newpavlov.
Closing this as we've gone with custom RNG crates to handle the issues on the
wasm32-unknown-unknowntarget, see #109. Forgetrandom 0.2, building forwasm32-unknown-unknownwill result in a compile-error by default. However, users can opt-in to using either awasm-bindgenorstdwebimplementation withgetrandom.
Right now,
stdwebdepends onwasm-bindgenso it doesn't really make a whole lot of sense to have two seperate implementations ingetrandomfor this.A better approach might just be to depend on the
web_syscrate from thewasm-bindgenrepo and eliminate the need for separate wasm32 features.I'm not sure how this would work with Node, but for Client Web, we could just use
Crypto::get_random_values_with_u8_array