On this page
Star History Monthly July 2026 | Building Blocks
Last month's terminal UIs were finished apps — you install lazygit, you use lazygit. This month we look at the opposite bet. In April, Mitchell Hashimoto published The Building Block Economy, arguing that the most effective way to build software and get massive adoption is no longer the polished mainline app but the building block: the embeddable component that other people's software is assembled from. His evidence is his own project — the Ghostty terminal took 18 months to reach a million daily update checks; libghostty, the library extracted from it, reached millions of daily users in two months by riding inside other people's apps.
His sharpest claim is about why this is happening now: AI agents are much better at gluing together proven, well-documented components than at writing everything from scratch — so the components themselves are becoming the growth story. Whether or not you buy the whole thesis, there's a set of star curves that look exactly like it. This month, four projects selling picks to the assembly economy: an embeddable terminal, a sync engine, a pair of code-review rendering primitives, and a JavaScript engine you've almost certainly run without knowing it.
The lineup
Four building blocks, each owning a different layer of the stack — and next to each, what gets built out of it.
| Project | Stars | The block | What gets built from it | Latest release |
|---|---|---|---|---|
| Ghostty (libghostty) | ~58.6K | Embeddable terminal emulation | Terminal apps, multiplexers, IDE panes | v1.3.1 · Mar 13, 2026 |
| Zero (rocicorp/mono) | ~3.3K | Client-side sync engine for Postgres | Instant-feeling web apps | zero 1.8.0 · Jul 13, 2026 |
| Pierre (@pierre/diffs, @pierre/trees) | ~5.5K | Diff and file-tree rendering | Code review UIs, AI coding tools | diffs v1.2.12 · Jun 29, 2026 |
| quickjs-ng | ~3.4K | Embeddable JavaScript engine | Plugin sandboxes, serverless runtimes | v0.15.1 · Jun 4, 2026 |
Terminals - libghostty
🔗 https://github.com/ghostty-org/ghostty
The essay's own proof of concept. Ghostty the terminal emulator is a 58K-star app — but the interesting part is libghostty, the library being extracted from it, starting with libghostty-vt: a zero-dependency (not even libc) terminal-sequence parser and state machine, announced in September 2025 with the argument that terminal emulation is duplicated effort everywhere because it's nobody's core business. The Ghostty app itself is now just the first consumer of its own library.
The ecosystem that grew in ten months is the story. cmux, a macOS terminal for agentic coding workflows built on libghostty, went from zero to ~25K stars in under six months — the second line on the chart above. Around it: Ghostling (the official minimum-viable-terminal example), libghostty-rs Rust bindings, official Go bindings, coder/boo (a screen-style multiplexer by Coder), muxy, an Emacs terminal, and an awesome-libghostty list to keep track of it all. Ghostty's 1.3.0 release notes claim dozens of projects, free and commercial, already embed it — notably before libghostty has even cut a stable versioned release. The C API is still marked unstable; the adoption came anyway.
Why it exists
- To make correct, fast terminal emulation an embeddable component instead of every app's side quest
- To let the Ghostty app and other people's terminals share one production-grade core
Tradeoffs
- No stable versioned release yet — the C API can still shift under early adopters
- The full library story (rendering, input, widgets) is still being extracted piece by piece
Best for: anyone building a product with a terminal in it — IDE, agent runner, multiplexer — who'd rather not write a VT parser from scratch.
Sync - Zero
🔗 https://github.com/rocicorp/mono
Zero is what happens when a team spends six years on one hard problem — client-side sync — and keeps re-shipping it as a better block. Rocicorp (Aaron Boodman of Greasemonkey and Google Gears fame, with Erik Arvidsson) built Replicache, then Reflect, then folded the lessons into Zero: a sync engine that pairs a client library with a server cache in front of your normal Postgres database. Queries run instantly against a local replica and sync in the background — the pitch on the repo is "99% of queries in zero milliseconds."
Zero hit 1.0 in March 2026 — its first stable release after more than fifty pre-releases — and has shipped a minor version roughly every two weeks since, reaching 1.8.0 in mid-July. The curve is the quiet-compounding kind: no viral launch spike, just steady accumulation as apps like Productlane and Ano rebuilt on it and the sync-engine debate (Zero, ElectricSQL, InstantDB, PowerSync, Convex) became one of 2026's liveliest infrastructure arguments. It's the smallest star count in this month's lineup — and probably the deepest technology.
Why it exists
- To make instant, offline-tolerant UIs a property of the data layer, not hand-rolled caching code
- To work against a normal Postgres schema instead of a proprietary backend
Tradeoffs
- You're adopting an architecture, not adding a widget — the sync engine shapes the whole app
- Young 1.x line in a crowded, fast-moving category
Best for: teams building web apps that should feel local-first — dashboards, trackers, collaboration tools — on top of Postgres they already run.
Diffs - Pierre
🔗 https://github.com/pierrecomputer/pierre
Pierre is the building-block economy at company scale — a startup that pivoted from app to blocks and got its growth curve back. The Pierre Computer Company (YC W23, founded by Bootstrap co-creator Jacob Thornton and early Twitter engineer Ian Ownbey) spent roughly three years building an opinionated GitHub competitor, pierre.co: hosting, review, and CI rebuilt from the metal. It shut down in 2026. What survived is the parts, shipped as products: diffs.com is @pierre/diffs, an open-source diff and code rendering library built on Shiki with split and stacked layouts, theming, and an annotation framework made for accept/reject review UIs; trees.software is @pierre/trees, the matching file-tree component. Both live in the pierrecomputer/pierre repo — created September 2025, past 5.5K stars ten months later.
The timing is no accident. Every AI coding product — agents, review tools, cloud IDEs — suddenly needs to render diffs and file trees well, and almost none of them want to build that from scratch. The paid layer underneath is the same bet: Code Storage, Pierre's hosted git infrastructure for codegen platforms — Thornton describes it as "kinda like what Stripe does for payments" — funded by a $23M round the company announces, characteristically, in plain text on its own site. The app didn't win; the blocks it was made of became the business.
Why it exists
- To make high-quality diff and file-tree rendering a drop-in dependency instead of every code tool's internal project
- To give the wave of AI coding tools a shared, polished review UI layer — extracted from a real production git platform
Tradeoffs
- Young libraries — trees is still in beta, and the API surface is evolving quickly
- UI primitives only: the review workflow around them is still yours — and the git plumbing underneath is Pierre's paid product
Best for: anyone shipping a tool that shows code to humans — review apps, agent UIs, internal platforms — who wants GitHub-quality diffs without building them.
JavaScript - quickjs-ng
🔗 https://github.com/quickjs-ng/quickjs
Proof that the pattern predates the essay. QuickJS — Fabrice Bellard's small, embeddable JavaScript engine — has been the block behind other people's products since 2019, when Figma rebuilt its plugin sandbox on QuickJS compiled to WebAssembly after its JavaScript-based sandbox kept springing escape vulnerabilities. You've "run" QuickJS every time you've used a Figma plugin; it just never had its name on the door.
quickjs-ng is the community fork keeping that block modern. Started in November 2023 by Ben Noordhuis and Saúl Ibarra Corretgé after upstream went quiet, it ships every couple of months, tests against the full ECMAScript conformance suite, and targets ES2023+ — and it's where new embedders land: Amazon's LLRT serverless runtime, the txiki.js runtime, radare2's scripting. Bellard's original has since woken back up, so the chart above is that rare thing: a fork and its upstream, both healthy, both shipping — the original with the stars, the fork with the release cadence.
Why it exists
- To keep a small, embeddable, spec-current JS engine actively maintained in the open
- To be the scripting layer for apps that need JavaScript without shipping V8
Tradeoffs
- An interpreter, not a JIT — you trade peak speed for size, startup, and sandboxability
- Two active QuickJS lineages means picking one (and tracking their drift)
Best for: products that need to run untrusted or user-authored JavaScript — plugin systems, edge runtimes, embedded scripting — inside a tiny, controllable engine.
Closing Thoughts
Put the four curves side by side and the essay's argument mostly writes itself. The biggest star count in this lineup belongs to an app (Ghostty) — but its growth story now runs through the library inside it, and the fastest riser this month (cmux, zero to ~25K stars in six months) is an app built from that library. Zero and quickjs-ng never tried to be apps at all, and Pierre's story is the sharpest version: three years spent competing with GitHub as an app, then a second life selling the parts. Blocks are infrastructure that shows up in your life as someone else's product feeling faster, reviewing code better, running plugins safely.
The star counts here are smaller than last month's TUI giants, and that's part of the point: building blocks are undercounted by every popularity metric we have. Figma has run QuickJS since 2019 without most developers being able to name it; libghostty had commercial adopters before it had a version number. If Hashimoto is right that agent-written software is assembled from proven components, the projects on this page are early entries in a category that's about to matter a lot — and star charts like these are one of the few places you can watch it happen.
