Thanks to @devsnek and @RReverser I just released v1.1.1 of wasm-feature-detect.
Smaller wit just 550B
CSP compatible
Runs in Node


https://npm.im/wasm-feature-detect …pic.twitter.com/x1FsGGvk2u
U tweetove putem weba ili aplikacija drugih proizvođača možete dodati podatke o lokaciji, kao što su grad ili točna lokacija. Povijest lokacija tweetova uvijek možete izbrisati. Saznajte više
Thanks to @devsnek and @RReverser I just released v1.1.1 of wasm-feature-detect.
Smaller wit just 550B
CSP compatible
Runs in Node


https://npm.im/wasm-feature-detect …pic.twitter.com/x1FsGGvk2u
What’s the purpose of promises if they’re resolved regardless of feature support and require manual handling of a flag? Wouldn’t it be better to resolve only when feature is supported and reject otherwise?
a rejected promise is equivalent to an exception. Feature detection should throw imo unless the detection process failed. Other example: fetch() doesn't throw on 500.
For such a young technology (stack), this is kind of sad. WASM't expecting that this kind of lib would ever be required 
The reason WebAssembly was standardized with extension in mind is so that all browsers could ship the MVP in sync (which they did!) All other features (that this library detects) are in the proposal stage and not part of the full standard yet.
Could it be made smaller by getting rid of the JS for each test and defining a successful standard return value? For example: if a test compiles and returns 42, we know the impl supports it.
Yeah, potentially. Happy to accept PRs :D But I think gzip is doing most of the heavy lifting here :)
Great! I see you use async module instantiation. I made before similar package but with synced & inlined wasm loaders:https://www.npmjs.com/package/wasm-check …
Also similar library from @svensauleauhttps://www.npmjs.com/package/webassembly-feature …
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.