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.
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.
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.
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...
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.
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 :)
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.
> 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!)
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.
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.
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.
As I mentioned in another comment, I find it easier to use Dear Imgui from a "lower-level language" like Odin or Go than to use any web framework with JS. You'd think that because web frameworks are so "high level" they would be better at expressing my intent. But actually the "lower level" tools are easier and faster and universally better. So which one is "high level" now? Which one is doing "more with less"?
As much as I dislike invasive tracking, I don't think the blame lies with Marketing on this one. In most cases I think you could implement all the awful surveillance you want with extremely minimal overhead, even on the web. Certainly malware developers are at the extreme of invasive + low-overhead!
Certainly there are cases where some manager says "put this script in Google Tag Manager and don't ask any questions", but rarely have I ever seen that be the bottleneck. Programmers actually just write really bad frameworks, and then other programmers use them to make even worse software, for literally no reason other than "maybe this framework design would be cool".
The Handmade community has been around for a decade now, well predating LLMs. Our values derive from Handmade Hero, which promoted a love for the craft of programming and an engineering mindset informed by deep understanding of how the computer and the platform actually work. The hallmark of the Handmade mindset is enthusiastically "reinventing the wheel", because building software from scratch, in the context of a specific problem, with a deep understanding of how computers work, can produce shockingly high-quality software.
Many people in or around the community have made great software over the years (4coder, File Pilot, RemedyBG, the RAD Debugger, Essence OS, Odin, raylib, kb_text_shape.h, Spall, etc.) but because it's a community of programmers, expertise in many "soft skills" is often lacking. This often prevents Handmade software from being a bigger success and sustaining its own development. Our goal is to fill in a lot of those gaps and help this amazing software achieve widespread success and redefine expectations for software quality across the industry.
We'll have a lot more details about what we do with the money once we actually start taking people's money.
No, we're still going to vet people. There's a slice of benefits we can offer to everyone who pays to become a member, but then on top of that we'll be able to provide tangible support for some number of projects as well, funded by the membership dues. Which projects we choose to support in this way will be at our discretion, and vetting the developer and the project is an obvious part of that process.
The thing we can offer developers, which is rather unique, is bespoke "Handmade-style" handling of many dull aspects of professional software: payments, licensing, email lists, websites, support, etc. The goal is to do these things without locking the project authors into a third-party platform; that is against our Handmade values and there are plenty of such products on the market today.
The goal was always, first and foremost, to teach. This is super obvious from the announcement trailer alone[1], where he says the point of the project is to pass on a way of life that inspired him. If Casey wanted to make money from a game he wouldn't have bothered with thousands of hours of Twitch streams.
It's a large community of programmers whose values align with those demonstrated in Handmade Hero. Naturally not all of those programmers are going to do carbon copies of Handmade Hero. Some make and publish their own software that is developed with similar values in mind (e.g. File Pilot, 4coder, Odin). Others just enjoy programming that way for fun and like to discuss their hobby projects with other like-minded people. This shouldn't really be surprising; this is to be expected of any online community.
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...