Finally reached the "Subject Matter Expert" phase of my career. The subject? An exploit targeting code I wrote. But progress is progress?
11.03.2026 14:38
👍 4
🔁 2
💬 0
📌 0
Finally reached the "Subject Matter Expert" phase of my career. The subject? An exploit targeting code I wrote. But progress is progress?
(We probably should just add some form of nominal types)
Another cursed way to emulate them: encode the name hash into a struct type, and add it as a nullable field to every struct. Apparently some toolchains have experimented with this (I won’t name names)
It’s only nominal typing if there is a “name”. Otherwise it’s just sparkling type identity
Your engineers were so preoccupied with potential perf regressions from removing asm.js optimizations, they never stopped to consider the one intranet site that somehow found a way to load-bear on them.
Also I had to cut this from the post, but existing compiler toolchains really don’t like to generate two files at the same time. It’s just apparently hard for them to simultaneously create a wasm and a JS file from a single source file. Seems silly, but it comes up in discussion.
It’s not insurmountable, emscripten does all this work today for C++. But getting it upstream seems to be a challenge. And upstream is the best developer experience for users.
Technically, I’m sure LLVM is fine with being aware of the web. The difficulty is how to integrate JS binding, glue generation, WebIDL parsing, platform integration, and a long tail of other issues. Does LLVM CI need to run browsers?
Also re: COOP/COEP. There's been movement to ease that restriction, but nothing concrete yet. Maybe with site-isolation becoming a de-facto standard we'll be able to do that.
I agree, the Web API/OS API split does make it harder to get started. But that's a much harder discussion for down the road (one I have mixed feelings on). We need the first-class integration with the platform as a first step. It won't solve everything of course though, life's not that easy.
Three Kringla with birthday candles.
If you’re not getting Kringla for your birthday, then what’s this all been about?
That’s awesome, I love to see new languages targeting wasm. If there’s ever anything not working quite right in Firefox, let me know!
I wouldn't lean entirely on the perf angle though, it's just one reason we're experimenting with this. The most important thing to me is making it easier to write and deploy wasm code on the Web. It's just way too hard for average devs getting started.
Doing the silly thing is unfortunately how wasm DOM apps work today. Batching up these calls requires architecting your whole framework around that concept, and is not ergonomic. It's also not a price JS has to pay, and a big part of this is trying to get to parity with JS.
I wrote a thing! Here's my hot take for where WebAssembly should go next:
hacks.mozilla.org/2026/02/maki...
Have you ever wanted to learn how a production JS engine works?
This video by Luke Wagner on SpiderMonkey is a great start. It's from a 2018 Mozilla event, and was just made public. Most of the details are still accurate AFAIK.
mozilla.hosted.panopto.com/Panopto/Page...
WebAssembly is a second-class language on the web, but how can we make it first-class? WebAssembly Components could be the answer…
hacks.mozilla.org/2026/02/maki...