This is where WASI (WebAssembly System Interface) comes in.
I absolutely disagree with ASC's stance on this, but it seems that the AssemblyScript project at least wants nothing to do with that kind of thing:
[1] https://devclass.com/2022/09/08/assemblyscript-project-wasi-...
[2] https://www.assemblyscript.org/standards-objections.html
> Languages that would naturally fit the Web platform not only are overlooked, but WASI's self-imposed abstinence of Web concepts undermines other languages' interoperability potential with JS and the Web platform specifically.
The problem is that objectively, the web platform is garbage. Half-baked, weirdly incomplete abstractions, most of can only be rationally explained as either historical accidents or the aftermath of political fights on standards committees. Why would anyone base a new abstraction around those if they don't strictly have to?
WASI is trying to be a cross language API for use by multiple languages that target WASM. But the author wants this API to more closely follow existing JS conventions? Sure that's useful to JS/Web, but it's not useful for anyone else trying to target WASM with a language that's not JS. And if you want to target Web API's with JS, can't you already just write native JS?
Bikeshedding over string encoding for example and objecting to WASI's promotion of UTF-8 because it doesn't match the encoding used by JS.
Say I write a Rust program to use `reqwest` to make a HTTP request to some API that is going to return me JSON.
I can compile it to... ELF with Rust I guess on Linux, or I can use Rust to compile it to:
> wasm32-wasi - when using wasmtime this is likely what you'll be using. The WASI target is integrated into the standard library and is intended on producing standalone binaries.
> wasm32-unknown-unknown - this target, like the WASI one, is focused on producing single .wasm binaries. The standard library, however, is largely stubbed out since the "unknown" part of the target means libstd can't assume anything. This means that while binaries will likely work in wasmtime, common conveniences like println! or panic! won't work.
> wasm32-unknown-emscripten - this target is intended to work in a web browser and produces a .wasm file coupled with a *.js file, and it is not compatible with wasmtime.
Say the Tokio async runtime works for wasm32-wasi (I don't think it does currently, I could be wrong) and reqwest + all of its network dependencies compile to wasm32-wasi (not sure if they do, I think there is progress) and say lite-json or some kind of JSON de-serizaliation works
Why would I compile + run as wasm32-wasi instead of stable-x86_64-unknown-linux-gnu?
Interesting links:
https://github.com/tokio-rs/tokio/issues/4827 - tokio support
https://github.com/async-rs/async-std/issues/505 - async-std support
https://www.reddit.com/r/rust/comments/h9bakg/could_not_find... - > There's no blocking implementation available for WASM. The WASM backend uses HTML APIs (fetch) and is supposed to run in a browser, where you can't block the event loop
After looking at the objections from these guys, they seem to boil down to, "but it makes non-web development more viable again, and that's bad for the web". The first part is true. The second part is arguable, but IMO if it is true, then balance needs to be restored.
Lmao. The guy is just mad that WASI uses utf-8, as opposed to utf-16 (which is what Javascript uses)
this has 7 weekly downloads... I would expect more?
So 7 weekly downloads sounds about right for an unknown package that is slower.