bvisness
Joined 8 years ago
Karma
302
Submissions
85
Member since
Oct 22
Recent submissions
Comment · 5 months ago
In SpiderMonkey, asm.js code has been compiled by exactly the same pipeline as wasm since at least 2019. In fact, the way we compile it is literally to construct a pseudo-wasm module and run it through our wasm compiler (with a few flags to tweak the behavior to fit the asm.js semantics). In other words, if you're running asm.js in Firefox, you're literally just running wasm anyway, so how could it possibly be faster?
Furthermore, if you use wasm, you'll have fewer bounds checks (because of better memory allocation strategies[1]), access to SIMD, bulk memory operations, and a host of other niceties that have been added to wasm over the years. If your asm.js code is outperforming someone else's wasm code, that probably just means their wasm code is worse.
[1]: https://spidermonkey.dev/blog/2025/01/15/is-memory64-actuall...
Comment · 5 months ago
Don't worry, YavaScript will live forever.
Comment · 5 months ago
Even a quick glance at the bugs revealed in the blog post would quickly disprove your theory.
Comment · 6 months ago
I can only speak for SpiderMonkey, as that’s the team I’m on, but we humans are definitely writing and reviewing the patches for these bugs. Sometimes the AI suggestions are good, often they’re not, and we never send off a fix for a security bug unless we thoroughly understand the problem and have assessed its severity ourselves.
Comment · 7 months ago
You can already make apps that write directly to a canvas today, and almost nobody does because they want what the DOM provides for them. Wasm changes nothing about the APIs available to web apps.
Comment · 7 months ago
The “single array of memory” is not the problem; that’s what all these languages already expect. The problem is the lack of meaningful memory APIs, e.g. virtual memory capabilities. I am co-champion of a proposal to fix this but have not been able to prioritize it for a while, unfortunately: https://github.com/WebAssembly/memory-control/blob/main/prop...
Comment · 7 months ago
A lot of the time I think you just won’t want to use multiple components. It’s nice to be able to compose them together, I guess, but in general it seems to me that a toolchain will typically just want to generate a single big component so that everything can interact without limits internally.
Comment · 7 months ago
This is not strictly true; there are synchronous APIs for compiling Wasm (`new WebAssembly.Module()` and `new WebAssembly.Instance()`) and you can directly embed the bytecode in your source file using a typed array or base64-encoded string. Of course, this is not as pleasant as simply importing a module :)
Comment · 8 months ago
As someone on the SpiderMonkey team who had to evaluate some of Anthropic's bugs, I can definitely say that Anthropic's test cases were definitely far easier to assess than those generated by traditional fuzzers. Instead of extremely random and mostly superfluous gibberish, we received test cases that actually resembled a coherent program.
Comment · 8 months ago
> I don't think making it a DOM controller is where the action is
Why not? I feel like people have gotten so used to the limitations of WebAssembly today that they've internalized JS as the only answer. But I don't really like JS, and would love to build web apps in other languages, and I totally would if it wasn't a huge pain (and slower too!)
Comment · 8 months ago
It's proposed here: https://github.com/WebAssembly/component-model/issues/598
Basically, it's sugar for `package` and `world` in the case where you aren't actually defining a world for others to use, and just for your own use. In such a case, the package and world names are irrelevant anyway.
Comment · 9 months ago
Most of the time it's genuinely much easier to use Rust or Go than to use Python or Node because the tools are just so much better. This is why I don't like judging "high level" or "low level" by some perceived position in the stack. All I care about is how well it lets me express my intent as a programmer.
Comment · 9 months ago
I don't know why people always bring up "but networks! but client/server!" when I point out that 100% client-side behavior is slow on the web.
Comment · 9 months ago
It's very easy to say the New Reddit devs were just "doing it wrong" and oversubscribing their components to Redux state, for example. (I love me a good `state => state` selector.) But also, this irrelevant-update problem was pervasive across all of New Reddit, across the app I worked on professionally for five years, and across many other applications I've looked at with the React and Redux dev tools. Irrelevant updates happen all the time with this stack.
If everyone who uses it seriously ends up "doing it wrong", I say it's the framework's fault.
https://twitter.com/its_bvisness https://handmade.network/m/bvisness