QIP: Quick Isolated Portable WebAssembly components: https://teapawt.org/t.co/fhKA3m9FXV blog: https://teapawt.org/t.co/EtrtGaXYON
Melbourne, Australia
Joined August 2013
- Tweets14K
- Following6K
- Followers1.9K
- Likes70.7K
Pinned Tweet
My WebAssembly debugger lets you time-travel with your scroll wheel.
WebAssembly (and Ghostty) are so fast that a step back just reruns from scratch.
Patrick Smith retweeted
Tell your agent to optimize your site’s web fonts. I’m seeing a huge difference on my blog.
Full prompt:
Make this site's web fonts load faster without changing how anything looks. Shrink font bytes as far as possible, keep rendering identical, and prove it with before/after pixel diffs. Treat any visual change as a regression unless I approve it. If an optimization would change rendering, tell me what it saves and what it changes, and keep the site looking the same by default. Keep the current loading behavior: don't touch font-display or fallback fonts. Don't add font processing to the build; write a script I run by hand, commit its output, and note when it needs rerunning. First measure the current state: each font file's size, glyph count, variable axes, OpenType features and hinting, plus font bytes per page and what each page preloads. Then find out what the site actually uses, checking inline component styles as well as stylesheets: which characters appear in the content, which axis values and weights each font needs (including one-off overrides and bold inside italics), which OpenType features are turned on, and CSS side effects like `hyphens: auto` using the U+2010 hyphen. Cut each font down to that. Keep the used characters plus Latin-1 and Latin Extended-A, and leave CJK to system fonts if that's how it renders today. Limit variable axes to the ranges in use, and only fix an axis at one value if nothing overrides it. Drop unused OpenType features and hinting. Split each font into two files. A small core with ASCII and the punctuation most pages use (curly quotes, dashes, ellipsis) gets preloaded. An extended file behind `unicode-range` only downloads when a page needs one of its characters. Each file's `unicode-range` should list only characters it actually contains. Watch out for a few things. A generated fallback face between the core and extended files will draw the extended characters before the real font does. Fonts with a Reserved Font Name under the OFL must be renamed internally once subset. Check the generated files, since font tools have quirks. Before calling it done, build a baseline from the same content and pixel-diff before and after on pages with code, italics, accented characters, components with their own font settings, and CJK. Explain every visible difference: content change, regression to fix, or harmless sub-pixel rounding. Re-measure bytes per page and confirm the extended files only load where needed. When you're done, tell me the bytes before and after per font and per page, the pixel-diff results, anywhere you deviated from what I asked and what it cost, and how to rerun the script. Later, it may be worth embedding the core font in the global stylesheet and precaching the extended files after idle.
Patrick Smith retweeted
There is an absolutely WILD story in this @GergelyOrosz podcast episode
1. An unnamed CTO of a cash-flow-negative company was debating doing layoffs. AI
2. He says "I don't want to hurt morale like that, I won't do it"
3. A few months later, he says to @GergelyOrosz that he's cash flow positive. WTF. How?
4. The company had been licensing a component from a licensing company that was critical for their business.
5. One day, a dev thinks "what if we got an agent to build our own?"
6. The agent does so well that they produce a BETTER, FASTER version of the component they were licensing.
7. They debate open-sourcing it, and they ask the licensing company about it
8. The licensing company panics, and says "we will pay you NOT to open-source this"
9. They also say "we'll also pay you extra so we can re-license it"
10. So a big outlay became a recurring windfall, thanks to the ingenuity of a dev asking the right question.
Individual contributors have never been more powerful. Think bigger.
youtu.be/mQu0zN4IvSI?si=P_v9…
TIL that GitHub Pages used to serve the CNAME config file on the website at GET /CNAME.
e.g. jekyllrb.com/CNAME
Not an issue, just interesting side-effect of what was likely unintentional.
ALT a lynn session research about GitHub Pages’ CNAME
The repo for the Flurry screensaver deserves many more stars: github.com/calumr/flurry
Patrick Smith retweeted
I like to look at claims like this in case I can improve Ghostty. I grabbed your source and immediately spotted the issue: your read loop overwrites a 64 KiB ring. Everything older is discarded unparsed per tick. You're faster because you're not actually terminal emulating.
It means the number isn't a throughput number. In a kitten benchmark run at the rate you're claiming, roughly 6.6 MB arrives per 60 Hz tick and 64 KiB of it gets parsed. You're read(2)-ing 100% of the data and parsing about 1% of it.
There are other minor issues (a small fixed scrollback in a preallocated ring buffer, no grapheme clustering, throwing away data like OSC 8 URIs, etc.), but the major one is simply that you're discarding ~99% of the input.
For plain text, e.g. your cat benchmark, the final screen ends up looking right, but the scrollback is missing 99% of the file and each retained chunk starts mid-line. As soon as there are escape sequences in the dropped spans, your emulator is fully out of sync and invalid: a cut inside a CSI prints the parameters as text, and any SGR, mode, title, or alt-screen change in the gap is just... gone.
FYI, this is why I don't like when people point at refterm as a terminal benchmark. refterm implements a TINY subset of what a terminal emulator must support, it's closer to a fast file reader, not a terminal emulator.
I also don't mean any shade by this. I like to look at technology objectively to try to learn something and improve my own craft and work. So I'm sharing what I found.
I modified your code very slightly to parse on every full buffer (rather than per tick). And the results are attached. Both use main commit in each repo at the time of this post.
Note the graph is in log scale, the discrepancy between performance for things like Kitty images is measured in GB/s.
Patrick Smith retweeted
Buckle up because this is some LinkedIn-quality bullshit.
There's a cliche story that goes like this:
Henry Ford had a problem with a generator no one could fix so he called in an engineer Charles Steinmetz. Charlie studied the machine for a while, made a chalk mark on it, workers adjusted that spot, the generator sprung back to life, and he handed over a bill for $10,000.
Ford was shocked and demanded an itemized invoice.
Steinmetz replied:
Making a chalk mark: $1
Knowing where to make the mark: $9,999
(and that's what I learned about B2B SaaS)
Anyway cool story but the point is that this is the same for software engineering! Code is getting cheaper by the second. Who gives a shit how many PRs you can generate? Any idiot can do this now. The real skill is knowing *what* PR to generate.
As of 2026, I think sufficiently hard engineering projects still require these skills that you can only acquire by actually understanding what code is doing.
Who can beat my implementation for unescape_html?
calculated.world/submissions…
ALT Median time: 775 ms Size: 24.8 KiB, gzip 15.2 KiB Memory: 22 pages (1.4 MiB)
TIL how <title> and <textarea> child text is defined to be different: fluffyandflakey.blog/2026/07…
Here’s lynn. It combines a shell with agents. Spawning an agent is like spawning a process. You can pipe between agents and different models. You can write `git status` without burning any tokens. Agents are read-only by default and only get write privileges when you decide.
cargo install lynn
Patrick Smith retweeted
LLMs make it easier than ever for normal software to get down to zero allocations.
Is this really a public company then?
ALT Anthropic admits its “novel” corporate governance structure “differs significantly” from most other public companies. It gives ordinary shareholders virtually no control over the company’s decisions. At the top of the structure sits a “Long-Term Benefit Trust”, which appoints its own members and generally has the power to elect and remove four out of the seven directors on Anthropic’s board. https://www.ft.com/content/a6c43402-719e-4295-ae5f-541edb0aeb29 ‘Bold but sane’: what we learnt from Anthropic’s 240,000-word IPO filing
We should think about what Hyrum’s law teaches us about security in the age of AI.
Hyrum’s law states:
With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
We can restate this for AI attacks:
With a sufficient number of attacks of an API,
it does not matter what you verify in behavior:
all potential vulnerabilities of your system
will be discovered by somebody.
Apple’s official guide for removing eMudhra root certificates: support.apple.com/en-us/1495…
Patrick Smith retweeted
Got a cheap embroidery machine off amazon for $300 where the biggest complaint is the mandatory $12/mo app that you’re forced to use. Had ChatGPT create its own app that communicates with the machine. Generative art patches incoming!
Patrick Smith retweeted
Corrupt autocracies prefer to do business with other corrupt autocracies because the profits are personal on both sides, not for the state or the country. No oversight, no investigations.
Patrick Smith retweeted
Yesterday, someone posted a task runner claimed to be 39x faster than Turborepo.
I got really excited, thinking they found some edge case in Turborepo and that I could make something way faster.
I open the benchmark repo, and its just straight up, flat out incorrect. Like, not even sorta useful. Not only was it not measuring the task runner parts of the script, it was overfit to a highly specific, completely unrealistic workload. 💀 The entire project is obviously Opus 5.5 vibe coded and Opus cheated the goal. Easy to miss if you're not experienced in build systems. Forgivable!
So, I open a PR to show that the algorithm being used can also make scheduling slower, by any arbitrary factor, with only a tiny adjustment. I chose 100x slower than Turborepo for demonstrative purposes.
The author fixed some of the problems but there are still grave issues. They're still comparing on an overfit bench that doesn't hold up when you insert the slightest variable, and *insisting* that its right. It is very obviously incorrect, but oh, well.
After revision, Turborepo is only 1.36x slower. Down from 39x, but a more realistic number nonetheless. So I figure: "Great! There must be something I can learn to make Turborepo faster."
I go digging, and it turns out the other tool is only faster still because it has correctness bugs. Once they correct those, they'll be roughly on par with Turborepo.
On top of that, the numbers they post now report with a mix of "% faster" and "✗ faster", using "% faster" whenever the difference isn't big enough to make their tool look good. 1.36x gets turned into "36%", which looks like more than it is to a casual observer.
This is a story of how I thought I was going to speed up Turborepo by 39x, and got nothing out of it.
I'm not mad; I'm just disappointed. 😄