Live data from Hacker News

WebAssembly: A promising technology that is quietly being enshitified

kerkour.com

11–20 of 64 posts

Re: WebAssembly: A promising technology that is quietly being enshitified

#12
post #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.

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 hereon, with regard to WASM.

Re: WebAssembly: A promising technology that is quietly being enshitified

#14
post #6

Earlier 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…

I agree, my personal take: if you don't want to get your hands dirty, WebAssembly is not ready for you yet. It'll take at least 5 more years before the tooling gets into a state where things should just work (especially DWARF support). I mean, we still cannot free memory! (actually there is a crazy way by recreating a new WebAssembly instance with a shrunk'd `ArrayBuffer`, but it requires you writing your own memory allocator)

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
post #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.

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…

I didn't know browser vendors supported WASI! I said that as some of us do not use WASI at all, just WebAssembly itself, so they can save some time by not reading this if they're not interested in WASI and/or its limitations.

Re: WebAssembly: A promising technology that is quietly being enshitified

#16

But 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?

Why not just come up with a new calling convention and implement it for a handful of popular languages?

Re: WebAssembly: A promising technology that is quietly being enshitified

#17

It'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…

Then maybe "this stuff" should not have been tacked onto the WASM standard in the first place? There's no free lunch. Sure, it sucks that your favorite garbage-collected interpreter/runtime bloats your module size. But the alternative option is to bloat every WASM engine by shoehorning your use case into the standard.

Re: WebAssembly: A promising technology that is quietly being enshitified

#19
Components are basically COM / CORBA for WASM. Just like COM enabled multiple languages to exchange structs and function calls with each other, WASM components do the same.

The 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

#20
I wish people would stop using the term "enshittify" to mean other things than what Doctorow coined it to mean. This has nothing to do with "enshittification" and there were plenty of other words to pick from.

I see the article says "sabotaged", so perhaps that was fixed? Or the titles never matched?

Post reply on HN