> In regular Tetris games, the speed at which the blocks fall steadily increases. This causes players to make more and more mistakes and, just like the holes in the S and Z columns, these mistakes will stack up until game over is inevitable. Ultimately, small mistakes due to the time constraints will likely be what causes your friend to lose the challenge, so you probably won’t have to wait 69,600 blocks to beat your friend.
If you explicitly list which functions you want to export from your WebAssembly module, the linker will remove all the unused code, in the same way that "tree-shaking" works for JS bundlers.
In my experience, a WebAssembly module (even with all symbols exported) is smaller than the equivalent native library. The bytecode is denser.
WebAssembly modules tend to be larger than JavaScript because AOT-compiled languages don't care as much about code size--they assume you only download the program/library once. In particular, LLVM (which I believe is the only mainstream WebAssembly-emitting backend) loves inlining everything.
Judicious use of `-Oz`, stripping debug info, and other standard code size techniques really help here. The app developer does have to care about code size, of course.
I second this; the tooling is somehow still not there after 10 years.
- The main toolchain for compiling existing C codebases to WebAssembly is Emscripten. It still hasn't escaped its tech-demo origins, and it's a rats' nest of compiler flags and janky polyfills. There are at least 3 half-finished implementations of everything. It doesn't follow semver, so every point release tends to have some breaking changes.
- The "modern" toolchain, wasi-sdk, is much more barebones. It's getting to the point of being usable, but I can't use it myself because it ships a precompiled libc and libc++ that use `-O3`, whereas Emscripten recompiles and caches the sysroot and uses `-Oz` if I tell it to. This increases the code size, which is already quite large.
- LLVM is still not very good at emitting optimized WebAssembly bytecode.
- Engines are still not very good at compiling WebAssembly bytecode to optimized machine code.
- Debug info, as you mentioned, is a total mess.
- Rust's WebAssembly tooling is on life support. The rustwasm GitHub organization was "sunset" in mid-2025 after years of inactivity.
- There is still no official way to import WebAssembly modules from JavaScript in a cross-platform manner, in the year of our lord 2026. If you're deploying to the browser and using Vite or raw ES modules, you can use `WebAssembly.instantiateStreaming(fetch(new URL('./foo.wasm', import.meta.url)))` and eat the top-level await. Vite recognizes the `new URL('...', import.meta.url)` pattern and will include the asset in the build output, but most other bundlers (e.g. Rollup and esbuild) do not. If you're on Node, you can't do this, because `fetch` does not work for local files. Most people just give up and embed the WebAssembly binary as a huge Base64 string, which increases the filesize by 33% and greatly reduces the compression ratio.
- If you want multithreaded WebAssembly, you need to set the COOP/COEP headers in order to gain access to `SharedArrayBuffer`. GitHub Pages still doesn't let you do this, although it's the third-most-upvoted feature request. There's a janky workaround that installs a service worker. All bets are off on how that workaround interacts with PWAs.
If the tooling situation had advanced past "tech demo" in the past 8 years since WebAssembly first shipped, a lot more people would be using it.
The header image in the article is a 2400x1600 PNG that is 500KB large, apparently due to subtle dithering making it hard to compress. Converting it to a visually-identical .avif (quality 90, 12-bit color depth) takes it all the way down to 15KB.
Yup, the CloudFlare CAPTCHAs are a nuisance, but they're so much better than the Google reCAPTCHAs they replaced. Those things must be designed to make you give up.
> The patent for the Cherry MX design finally expired in 2014.
OK, but did it really? I've seen this claim pop up occasionally, but nobody ever points to the patent in question. A quick Google search for "cherry mx patent 2014" shows the oldest result as being a Reddit comment from 2017 (https://www.reddit.com/r/hardware/comments/6am47a/comment/dh...):
> The patent expired in 2014. Many people have been paying the same price for mechanical keyboards with cheaper Chinese MX switches without knowing.
> For 20 years, Cherry’s patent on mechanical switches made it the only player around. That patent’s expiration around 2014, though, released the floodgates and allowed countless copycats and switches with varying levels of modification to the cross-stem design to pour in.
However, what seems to be the actual Cherry MX switch patent (US4467160A) was filed in 1983 and expired all the way back in 2003. So what exactly expired in 2014?
For a much more substantive article on a similar topic, see Dan Luu's blog post which draws an analogy to talent scouting in baseball: https://danluu.com/talent/
Am I missing something? The LGPL only applies to the library itself--you can dynamically link to it from proprietary code. So in this hypothetical scenario, someone could just write a terminal emulator (or IDE, or what have you) that dynamically links to libghostty and put as much telemetry in it as they wanted, couldn't they?
I was going to wait to post this until I've finished the CLI and documentation, but this seems like a relevant time to plug my web font subsetting/self-hosting tool: https://glypht.valadaptive.dev/
It lets you pick from the Google Fonts catalog, and comes with various options for further reducing the fonts' sizes if you're as obsessed with webpage size as I am.
You can also subset your fonts; e.g. if your content is in a language that uses the Latin alphabet, then you only need to include those characters in your font. Between that, variable fonts, and WOFF2, I've managed to get Inter down to 50kB (plus another 50 if you need real italics).
> In regular Tetris games, the speed at which the blocks fall steadily increases. This causes players to make more and more mistakes and, just like the holes in the S and Z columns, these mistakes will stack up until game over is inevitable. Ultimately, small mistakes due to the time constraints will likely be what causes your friend to lose the challenge, so you probably won’t have to wait 69,600 blocks to beat your friend.