21–30 of 251 posts
WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?
> garbage collection The draft WASM garbage collection proposal is partially implemented in Chromium, you can try it by enabling the enable-experimental-webassembly-features feature flag. > DOM access WebAssembly will never have direct access to the DOM, but at least with Rust the wasm-bindgen+web_sys crates make interacting with the DOM as simple as it is from JavaScript.
WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?
Unpopular opinion: Users will eventually realize that the lowest common denominator between languages is ... a BYTE STREAM (e.g. JSON/CSV/HTML), or what I think of as shell / Unix / Web -style composition.
IDLs and code generators are useful in many limited domains (e.g. when you control both sides of the wire), but they bake in a lot of assumptions that people don't realize are language-specific.
e.g. Protobufs are very good for C++ C++ communication, but Java and Python users seem to dislike them equally, and even Go users do too.
COM is probably better than what most people are proposing now -- it recognizes the problem is dynamic, rather than trying to create the leaky abstraction of "fake" static system. It's true that IDL is reinvented every 5 / 10 / 20 years. (Related recent story: https://news.ycombinator.com/item?id=30128048)
I expect WASM will get some kind of component system (if it doesn't already exist), but many apps will still need to fall back to something more general.
-----
I'm writing about byte streams as a narrow waist of interoperability now, and this is the "lead in" review post: http://www.oilshell.org/blog/2021/12/review-arch.html
Even though disparate WebAssembly components can run in the same process (with memory potentially shared by the host), for something as wide as the "Web", the lowest common denominator is still the common text-based interchange formats we already have.
Related comment on WebAssembly: https://news.ycombinator.com/item?id=28581634
Programmers underestimate the degree to which languages and VMs are coupled i.e. I question whether WebAssembly is truly polyglot, i.e. GC requires a richer type system in the VM, and types create languages that are winners or losers. Losers are the language implementations that experience 2x-10x slowdowns.
WASM has been at an inflection point for 5 years. Where are we at with garbage collection and DOM access?
I'm really happy to see more people bringing their attention to the Wasm ecosystem. There are tons of opportunities on this space. Regarding WAPM [2] and how its development had become a bit dormant, expect news about it soon. Can't wait to share what we have been working on!
[2] https://wapm.io
I’m waiting for a Docker container with a WASM runtime. Wait, maybe someone’s already done that… /s PS - actually, originally I was being sarcastic, but there probably are some very good security use cases for it.
You joke, but this is a thing: https://krustlet.dev/
WebAssembly is full of potential. But so are Java bytecode, SPIR and various others. Why will WebAssembly take off where these haven't?
Not owned by shit for brains Oracle.
Like the inability of interact with the DOM (or other browser APIs) without calling out to JavaScript.
Or the fact that you had to split up the code on your side into a JavaScript part (these days, perhaps transpiled from Typescript) and a part that was Java code then and is now Rust or C/C++ in case of WebAssembly. It goes without saying that these are very different developer experiences with virtually no overlap in toolchains and programming languages.
Oh and of course even WebAssembly suffers from browser fragmentation. Not only will performance be different, depending on whether you run your wasm module in Chrome, Safari or Firefox. These browsers do also not implement the same feature set (atop the basic wasm MVP). Like Safari doesn’t have SIMD. Other important additions (like tail calls, garbage collection and others) are also not yet universally supported.
For the sake of WebAssembly I do hope that they’ve learned their lessons from why Java applets (and Silverlight, Flash, PNaCl) all failed.
Hey, I'm Syrus From Wasmer [1]! I'm really happy to see more people bringing their attention to the Wasm ecosystem. There are tons of opportunities on this space. Regarding WAPM [2] and how its development had become a bit dormant, expect news about it soon. Can't wait to share what we have been working on! [1] https://wasmer.io [2] https://wapm.io
Yeah, nah: https://github.com/zandaqo/iswasmfast
JS is about 10x faster than wasm in simple linear regression, and 30% faster in levenstein distance calculation.