ASTROHACKER

Chromium Only (For Now): Why We Shelved WebKit and Ladybird

July 21, 2026 · Ryan X. Charles

You open https://astrohacker.com in a pane, put Astrohacker TermSurf into native fullscreen, and the glyph rain keeps moving. Links still navigate. The page is not a frozen screenshot of yesterday’s Space.

That is the Chromium path working the way a hosted browser should.

What you will not find in a current install is a second or third shipped engine helper. No ah-webkitd. No Ladybird. No “reserved Gecko” story on the product surface. One browser engine ships: Chromium.

On July 20 we field-noted 0.1.47 through 0.1.60— TermSurf by name, Browse first, ahcalc, focus that stays local. This post is what happened after that line: a hard day of engine work, then an honest cut.

The short version

  • Shipped browser: Chromium only — panes, Homebrew package, warmups, docs, and marketing product copy.
  • Archived (not erased): WebKit and Ladybird leave the active product. Patch history, closed issues, and old blog posts stay. They can return under new issues later.
  • Gecko residual scrubbed — it was never a public ship engine; we stopped advertising it as reserved future furniture.
  • Chromium maturity first — fullscreen / Mission Control freeze fixed for live webviews (helpers join the host Space; we did not ship a permanent “never background anything” hammer).
  • We tried before we cut — WebKit got a live compositor path (rain that actually animates). Ladybird still painted black after real pin work. Cost stayed high; daily use stayed Chromium.
  • Also this window: ahcalc no longer dies on Bun’s compiled /$bunfs/… argv; browser chrome labels follow a naming convention instead of a hard-coded engine table.
  • Line — monorepo product crates through 0.1.68; upgrade the cask when your tap has the Chromium-only package.

If you only remember one sentence: we proved multi-engine can work; now we ship one engine well so it can become boringly reliable—and invite the others back when that job is done.

Why remove WebKit and Ladybird

Not because multi-engine was a fantasy. Astrohacker TermSurf already ran real engines in terminal panes. Chromium, WebKit, and Ladybird were not slideware. Gecko work produced scaffold and hard lessons (why Gecko is the hard one) without a public ship contract.

The problem is attention.

Each engine is a fork, a helper, a presentation path, packaging, warmups, docs, and a long tail of input and paint special cases. WebKit alone ate live compositor work, hover paths, and build-shore qualification. Ladybird ate pin isolation and still showed a black pane that navigated and titled correctly while pixels refused to show. Chromium, the engine we actually live in for product development and most web-developer testing, still had gaps—like webview freeze after the host window changed Space or entered native fullscreen.

Spreading effort across three (or four) engines leaves none of them at “this is finished.” That is a bad trade for an early product.

So we made a deliberate cut:

  • Park WebKit and Ladybird on the active product surface.
  • Focus on Chromium until it is mature enough that “open a URL in a pane” stops being a research project.
  • Keep the door open — multi-engine is architecture we already exercised. When Chromium is the solid default, other engines can earn a new issue and a new ship contract. History under patches/ and the issue archive is how we reconstruct them—not a half-dead helper in every cask forever.

Not “we hate WebKit.” Not “Ladybird failed forever.” Not “multi-engine is dead.”

It is: one mature engine beats three half-done ones—for now.

What we did before we cut

Removal is easier to trust if you see the day we spent trying.

Fullscreen that stays live (Chromium)

With the marketing site open, entering native fullscreen or moving the host to another Mission Control desktop could freeze the page: rain stopped, clicks died, the TUI stayed fine. Helpers had been left on the previous Space while the host moved.

We fixed that on the Chromium path by co-locating helper source windows with the host (or joining Spaces for non-visible helpers)—not by leaving a permanent process-wide “disable occlusion backgrounding” flag in product spawn. Windowed browsing, resize, focus, and cleanup stay ordinary. Fullscreen should feel like the same browser, bigger.

That is the kind of defect we want headroom to chase next: presentation, Spaces, polish, packaging—one stack at a time.

WebKit: live rain, still expensive

WebKit’s old presentation path was snapshot-backed: capture bitmaps on discrete events, ship those to the host. CSS animation and hover did not keep the pane alive. We pushed a live compositor path so glyph rain could run for a full minute without click-to-repaint theater, and we chased hover authority after that.

Those issues closed as real progress. They also proved the bill: fork builds, compositor seams, input special cases, two build shores, continuous tax. The operator disposition was blunt: WebKit is not the day-to-day engine; Chromium is. After Ladybird left, keeping WebKit as a second full ship contract was still too much surface for MVP.

So WebKit left the active product the same way Ladybird did: out of Homebrew and packaging, out of living docs and marketing claims, live fork no longer required. Historical patch series and issues remain. Hover and other WebKit product work are out of scope unless a future issue reopens the engine.

Ladybird: black pane, then out

Ladybird still reported title, URL, and engine identity while painting a large black rectangle—presentation, not “failed to spawn.” We offered render services more uniformly, isolated pin hypotheses, and closed the paint issue for MVP without a full pixel fix: multi-engine was already proven by Chromium + WebKit; Ladybird was not required to ship.

Then we removed Ladybird from the active product surface entirely—release path, pin, code, website—while keeping historical archives. A cask/tarball mismatch on the way out taught the usual packaging lesson: formula body and archive contents must stay in lockstep. The install story is Chromium-only now, on purpose.

Gecko residual

Gecko was never in the Homebrew ship set. After WebKit and Ladybird left, living docs and crates still whispered “reserved” or kept scaffold around. That confuses a Chromium-only product. We scrubbed the active residual and left the historical narrative alone. No claim that Gecko “ships someday” until someone opens a real issue and finishes the work.

Small product fixes in the same window

Engine cuts were the headline. Two smaller changes still matter when you upgrade:

  • ahcalc — the compiled one-binary client was rejecting Bun’s synthetic /$bunfs/root/ahcalc argv entry as a user argument. Normal no-flag launch works again; real flags and --server still mean what they meant.
  • Browser labels — pane chrome no longer depends on a hard-coded map of engine families. Helpers named like {prefix}-{stem}d display as {stem} (ah-chromiumd → chromium). Selection and routing are unchanged. When another engine returns, labeling does not require rewriting a private allowlist first.

What still ships

Same install story, narrower engine list:

brew tap astrohackerlabs/astrohacker
brew trust astrohackerlabs/astrohacker
brew install --cask astrohacker

Or:

brew update
brew upgrade --cask astrohacker

App: /Applications/Astrohacker TermSurf.app. On PATH you still want ahterm, ahsh, ahweb, ah-chromiumd, and ahcalc. You should not expect WebKit or Ladybird helpers in a current package.

Still one cask. Still Apple silicon. Still The Agentic Hacker’s Terminal as slogan—even when the app on disk is TermSurf and the browser inside it is Chromium.

Worth five minutes after upgrade:

  1. ahweb https://astrohacker.com — type into the page (Browse-first from 0.1.60 still applies).
  2. Enter native fullscreen — rain should keep moving; a link click should navigate.
  3. Run ahcalc with no flags — it should start the client path, not die on a bunfs path argument.
  4. Confirm you are not hunting for ah-webkitd or Ladybird in the cask.

Protocol and product docs: How TermSurf Talks, /docs, Chromium docs. Prior field notes: 0.1.60.

What this does not change

  • TermSurf as the wire language and multi-pane host model.
  • Historical posts and issues that named WebKit, Ladybird, or Gecko—those are the record, not active claims.
  • Willingness to run more than one engine again when the primary path is mature enough that second engines are a choice, not a distraction.

Upgrade. Use Chromium panes hard. File Chromium bugs. When the default browser path is boringly solid, other engines can come back the right way: a new issue, a real ship contract, and a product that already works with one engine at full strength.

← Back to blog