HN DigestHacker Newsletter, digested

Issues

Issue #808

11 postsRead the newsletter ↗

Don't skip

#Code

The browser's main thread is expensive

  • kciter.so
  • 436 points
  • 151 comments
  • 29 min read

Web jank usually comes from code holding the browser's single main thread, not from slow code. Lee Sun-Hyoup describes two families of fixes, each with an interactive demo. One spends the main thread's time better by splitting, batching, prioritizing and deferring work. The other moves work to the compositor or a web worker, or drops it entirely.

A long, demo-backed tour of every way to keep the main thread free, from yielding and batching to FLIP and workers, and the thread pushes back that bundle size and hydration hurt more.

#Favorites

Bug Blindness

  • danluu.com
  • 407 points
  • 287 comments
  • 30 min read

Dan Luu argues that most people hit the same bugs he does and stop seeing them. The teams that build software are the worst at it. People learn unconscious workarounds, or they are fans of the product. Luu thinks pointing bugs out cures this quality blindness, and that coding agents make the cure more urgent.

Dan Luu on why products ship badly broken while internal reviews call them great, and how noticing bugs is a skill people can learn.

Worth your time

#Favorites

Porting my 1993 Amiga game to Godot, with an LLM reading the 68000 assembly

  • babyloniantwins.com
  • 381 points
  • 133 comments
  • 21 min read

The author of Babylonian Twins wrote the Amiga game in 68000 assembly in sanctions-era Baghdad in 1993. He had Claude Fable 5 port both the 72,758-line original and his 2010 C++ remake to Godot. It reverse-engineered undocumented level, object and sprite formats on its own, mostly in an evening each. The bugs it left were subtle ones he found only by playing.

A detailed account of an LLM rebuilding 68000 assembly byte-for-byte and porting a 1993 game to Godot, including the bugs it introduced, with commenters comparing their own ports.

#Data

How accurate have Ed Zitron's AI skeptic predictions been?

  • danluu.com
  • 879 points
  • 1,056 comments
  • 56 min read

Dan Luu checks about 30 dated predictions the AI skeptic Ed Zitron made in 2024 and 2025. They include that AI had peaked, that OpenAI's revenue forecasts were near-criminal, and that Cursor would die. Luu scores nearly all of them wrong. He says Zitron's numbers decorate anger more than they support an argument.

Dan Luu checks a prominent AI skeptic's dated predictions one by one against what happened, a lesson in judging forecasts on either side, and the thousand-comment thread disputes the scoring.

#Design

GUIs should be fully keyboard-driven

  • ckardaris.com
  • 1,055 points
  • 528 comments
  • 2 min read

Being keyboard-driven is a weak argument for building TUIs instead of GUIs. Nothing stops a GUI from being fully usable by keyboard. Platform guidelines already ask for it. So a GUI that can't be driven from the keyboard shows a missing effort by its developer.

A short case that keyboard support is a matter of effort, not interface type; the large thread is the real value, with practitioners on focus order, the curb-cut effect and situational disability.

#Learn

Aging brains blend memories together instead of just forgetting them

  • studyfinds.com
  • 353 points
  • 156 comments
  • 7 min read

A 61-person fMRI study in Cerebral Cortex finds that older adults' memory errors are often mix-ups, not blanks. In young adults, hippocampal replay predicts accurate recall. In people over 60, the same replay predicts cross-category mix-ups. Neither brain shrinkage nor attention explains the shift.

An fMRI study finding that older brains blend related memories rather than simply losing them, with a neuroscientist in the thread adding context.

If you have a minute

#Design

How I Design with AI

  • ref.tools
  • 24 points
  • 12 comments
  • 4 min read

Matt Dailey, founder of Ref, argues that AI-generated product design looks the same everywhere. He blames agents that pile on extra elements, and teams that spot-fix complaints one at a time. His fix is to write down the design constraints first and cut whatever the agent adds that isn't needed. He then iterates on several variants in a real design tool before touching the codebase.

Seven practical rules from an engineer without a designer, built on Christopher Alexander's idea of settling the constraints before the solutions, with the team's own showcase page and preview deploys as examples.

#Code

Fine, I'll build my own text editor

  • dbushell.com
  • 263 points
  • 263 comments
  • 3 min read

David Bushell prototypes a browser code editor three ways. Canvas rendering leaves screen readers with nothing. Contenteditable slows down on long files. A plain textarea with a highlighting layer on top is the most workable base.

Three attempts at a browser text editor, built on canvas, contenteditable and textarea, each with a live demo, and a note on why UTF-16 length is not grapheme count.

#Working

No AI Fridays

  • noaifridays.com
  • 295 points
  • 209 comments
  • 2 min read

A one-page campaign site asks developers to switch off AI assistants one day a week and write code by hand. It cites studies linking LLM use to cognitive debt, weaker critical thinking and poorer skill formation. It argues that if AI's productivity gains are real, one day without it costs little.

A thin manifesto for one AI-free workday a week, worth it for the polarised thread of first-hand accounts on skill loss and learning.

#Favorites

Calibrate Before You Accelerate: Bias Toward Action in a New Role

  • tucker.wales
  • 188 points
  • 80 comments

In a new role, a bias toward action pays off only after you have built context. The author describes phases: first learn how things work and why, then make visible changes. He cites Chesterton's Fence against removing what you don't yet understand.

On whether to change things early or first understand them in a new role, mostly through a thread of former CTOs' experience and Chesterton's fence.

#Design

“I just chose words carefully”

  • unsung.aresluna.org
  • 1,255 points
  • 353 comments
  • 2 min read

Fully justified monospace text looks bad because spaces can't be split evenly and hyphens stand out. In the late 1990s, rs1n avoided both in a Super Metroid guide by picking words so every line ended exactly at the margin. He did it by hand, for 17,000 words.

Marcin Wichary on a 17,000-word game guide fully justified in monospace purely by word choice, and readers checking whether TV screenwriters did the same.

Also in this issue

Everything else is in the full newsletter ↗