WebAssembly: A promising technology that is quietly being enshitified
1–10 of 64 posts
Re: WebAssembly: A promising technology that is quietly being enshitified
#2It's hard because, a lot of this stuff (async WASM, effect-driven WASM, GC in WASM, etc) is all driven by the desire to push these concerns out of wasm bytecodes, because it explodes the binary's size.
I have a pretty trivial webapp written in Yew and I stopped working on it once I saw that the wasm artifacts were weighing at 4MB (uncompressed) for relatively little functionality. THIS is what is driving the next round of "work" on WASM: to wring more functionality out of a system (WASI 0.1) designed as a drop-in replacement for emscripten output. As an aside on this point, the author is waaaay in front of their skies with basically all of their critiques around ByteCode Alliance; A lot of innuendo to basically serve a rhetorical point that isn't really true (WASI 0.1 is "good enough"). It has drawbacks! That's what the iterations on the protocol are exploring!
And this tech is cool and all, but right now a reasonably-vanilla typescript react app w/ a modern bundler (ie including stuff like router, redux, oidc, etc) is beating the breaks off of a similar app in Rust or C#/Blazor in terms of bin size. And there's no perf or API-surface argument that overcomes this. And it has chilling effect on developers when they reach for this tech.
Re: WebAssembly: A promising technology that is quietly being enshitified
#3> We're sorry but this website doesn't work properly without JavaScript enabled. Please enable it to continue.
Re: WebAssembly: A promising technology that is quietly being enshitified
#4It's hard because, a lot of this stuff (async WASM, effect-driven WASM, GC in WASM, etc) is all driven by the desire to push these concerns out of wasm bytecodes, because it explodes the binary's size . I have a pretty trivial webapp written in Yew and I stopped working on it once I saw that the wasm artifacts were weighing at 4MB (uncompressed) for relatively little functionality. THIS is what is driving the next ro…
It really depends on what you're using. If you use Rust with `wasm32-unknown-unknown`, you'll likely get small binaries (<200 kB). If you use C++ and Emscripten with all features enabled, then yeah you'll have multiple megabytes with all the libcxx and musl stuff.
Re: WebAssembly: A promising technology that is quietly being enshitified
#5It's hard because, a lot of this stuff (async WASM, effect-driven WASM, GC in WASM, etc) is all driven by the desire to push these concerns out of wasm bytecodes, because it explodes the binary's size . I have a pretty trivial webapp written in Yew and I stopped working on it once I saw that the wasm artifacts were weighing at 4MB (uncompressed) for relatively little functionality. THIS is what is driving the next ro…
It really depends on what you're using. If you use Rust with `wasm32-unknown-unknown`, you'll likely get small binaries (<200 kB). If you use C++ and Emscripten with all features enabled, then yeah you'll have multiple megabytes with all the libcxx and musl stuff.
My direct experience with wasm32-unknown-uknown contradicts your own. I am building a yew on nightly, moving between release or debug affects nothing.
Re: WebAssembly: A promising technology that is quietly being enshitified
#6Earlier quoted context omitted.
It really depends on what you're using. If you use Rust with `wasm32-unknown-unknown`, you'll likely get small binaries (<200 kB). If you use C++ and Emscripten with all features enabled, then yeah you'll have multiple megabytes with all the libcxx and musl stuff.
My direct experience with wasm32-unknown-uknown contradicts your own. I am building a yew on nightly, moving between release or debug affects nothing.
> moving between release or debug affects nothing
I'd start with that, it's an obvious red flag. Switching between both should create huge differences. Also look into `wasm-opt` from the Binaryen project for post-link optimizations, `wasm-ld` from LLVM isn't that great at DCE.
Re: WebAssembly: A promising technology that is quietly being enshitified
#7You have been blocked, apparently Android Chrome is a malicious browser.
Re: WebAssembly: A promising technology that is quietly being enshitified
#8You have been blocked, apparently Android Chrome is a malicious browser.
Just had it too, refreshing worked.
Re: WebAssembly: A promising technology that is quietly being enshitified
#9> If you are using WebAssembly in a web browser then you are good, WASI does not concern you.
In case you absolutely do not care for WASI but love WebAssembly for the web.
Re: WebAssembly: A promising technology that is quietly being enshitified
#10Earlier quoted context omitted.
My direct experience with wasm32-unknown-uknown contradicts your own. I am building a yew on nightly, moving between release or debug affects nothing.
> moving between release or debug affects nothing I'd start with that, it's an obvious red flag. Switching between both should create huge differences. Also look into `wasm-opt` from the Binaryen project for post-link optimizations, `wasm-ld` from LLVM isn't that great at DCE.
Thanks for the feedback.
I was wrong about debug vs release; It's the difference between 4.0MB & 893KB on a ~500 LOC rust codebase (per cloc).
I want to observe that your suggestions don't undermine or refute my point about problems that WASM adoption faces. This serves to underline that the developer experience needs work. Opinions may differ on how much. Also that "developer experience" runs on multiple axes of concern (bin size, perf, accessibility, utility of language, etc).