You have been blocked, apparently Android Chrome is a malicious browser.
Just had it too, refreshing worked.
WebAssembly: A promising technology that is quietly being enshitified
11–20 of 64 posts
Re: WebAssembly: A promising technology that is quietly being enshitified
#12> 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.
And keep in mind that the perspective of the author is that things will only get worse from hereon, with regard to WASM.
Re: WebAssembly: A promising technology that is quietly being enshitified
#13Re: WebAssembly: A promising technology that is quietly being enshitified
#14Earlier quoted context omitted.
> 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 con…
My point is: if you're comfortable working with a slightly obscure microcontroller, then you won't have much problems. LLVM supports WebAssembly out of the box, so it mostly feels like programming for one of those.
Anecdotally: we run a large Rust app in under 1 MB of WebAssembly at Zscaler.
Re: WebAssembly: A promising technology that is quietly being enshitified
#15> 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.
I don't think there's any guarantee that browser vendors will continue to support WASI 0.1 indefinitely; Once multiple versions of the standard are in play, codebase supporting them simultaneously explode in size. None of this gets into the likelihood that, once WASI hits 1.0, the prior versions very well could be "retired". And keep in mind that the perspective of the author is that things will only get worse from h…
Re: WebAssembly: A promising technology that is quietly being enshitified
#16But WebAssembly is one of the most promising opportunities in a long time to escape the C ABI problem. Why should we squander that? Do we want to be stuck writing C forever?
Re: WebAssembly: A promising technology that is quietly being enshitified
#17It'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…
Re: WebAssembly: A promising technology that is quietly being enshitified
#18> I strongly believe that async is the new billion dollar mistake of the 2020's: a design aberration that wasted so much developers time that it had cost billions of dollars to companies.
Yes. Nicely put
Re: WebAssembly: A promising technology that is quietly being enshitified
#19The C ABI approach works fine but becomes complicated when you want to pass things that aren't fixed-length, because unlike the C ABI usage when linking different libraries into the same address space, the host and the module run in different address spaces. Eg if the host wants to pass a string to a module fn, it first needs to call a different "malloc" module fn to allocate some space in the module address space and return that address, then the host writes the string to that address, then calls the original fn it wanted to call with that address, then calls a third "free" function at the end to release that allocation. Does that work? Of course it does. But the component ABI abstracts over all that for you and lets you call the function with the host's string type, and the runtime on the host side and bindings on the module side handle all the thunking so that it appears on the module side as the module's string type.
TFA doesn't seem to have any arguments other than "It's too many new words for me to learn so it's unnecessary I decided." Eg:
>And don't get me started on WIT's kebab-case identifiers (function names, interface names...). Why??? How can a specification about cross-language interoperability can come with a convention that basically no programming language use?
The point of the kebab case is that it does *not* show up in the generated bindings. It's processed by the bindings generator into the appropriate casing for the language. Eg a function name `foo-bar` becomes `foo_bar` in Rust, and a type named `foo-bar` becomes `FooBar`.
Re: WebAssembly: A promising technology that is quietly being enshitified
#20I see the article says "sabotaged", so perhaps that was fixed? Or the titles never matched?