DEV Community: Anton Shubin

preact-components: a Preact component library without shadcn or Radix

Anton Shubin — Wed, 30 Sep 2026 16:42:52 +0000

TL;DR

preact-components is my open-source Preact component library: ten JSR packages, rendered on the server, with roles, keyboard handling and focus written by hand.
I own my components instead of using shadcn, Radix or MUI, because working around their styling, upgrades and limits cost me more than owning them.
Owning components means owning accessibility, so headless Chromium checks the keyboard handling on every pull request.
It is beta: no screen reader has been run against it, only Deno is tested, and it is Preact and Tailwind only. Try any component in the live guide first.

preact-components: Live: Open the live UI guide · Code: github.com/spy4x/preact-components

Every new app I start needs the same things: a button, a table, a dialog, a form
field, a chart, a signed-in layout. I kept rebuilding them, or pulling in a
component library and then working around it.

preact-components is where that stopped. It is an open-source Preact component
library: ten packages on JSR, every component rendered on the server and
hydrated in the browser, with roles, labels, keyboard handling and focus written
by hand. No shadcn, Radix, Headless UI or Material underneath.

This post is for developers who build with Preact and Tailwind and wonder
whether owning the UI layer is worth it. I'll show why I decided it is, what is
in the ten packages, how to try it in a minute, and what is not done yet.

The dashboard above is on the guide's first page. Every part of it is a
component from these packages, running on local state: you can filter and sort
the projects, run the checks for a toast, and add a project in the dialog.

Why not shadcn, Radix or MUI?

Two of my earlier apps used shadcn, Radix and bits-ui. Over time those libraries
cost me more to work around than it would have cost to own the components, in
three ways:

Styling opinions. A library ships a look. I already had design tokens. Either I fight its defaults on every component, or I slowly give up my tokens. The second one wins, quietly.
Upgrade breakage. A component library changes its API and its rendered markup. Every upgrade reopens components that already worked, for no product reason.
Extension limits. The component I need is never quite the one it ships. The workaround is often more code than the component, and it inherits the library's constraints on top.

So the repository has a written rule: every component is written there. No
third-party component library is a dependency, and a copy of one pasted into the
tree counts as one too. The old apps are still useful, but only as a reference
for design intent: I read how they compose a dialog and write my own.

Port the markup and the behaviour. Never the dependency.

That doesn't mean I write everything. My rule is "own the small, keep the huge".
Preact, signals, Tailwind, arktype, wouter and Leaflet stay: they are large,
well-solved problems, and none of them is a component library. A button, a
dialog or a combobox is small enough to own, and opinionated enough that I'd
fight someone else's defaults.

The real price: accessibility

Owning components means owning everything a library used to hide. The repository
names it plainly, so nobody pretends it is free:

focus traps: moving focus into a dialog, keeping it there, returning it on close;
dismissal: an outside click, Escape, and the difference between dismissing and closing on purpose;
ARIA wiring: which role, aria-expanded or aria-labelledby goes on which element;
keyboard navigation: arrow keys, Home and End, typeahead;
positioning: anchoring a popup to its trigger and flipping it when it would overflow.

Where the platform already has an answer, I use it: native <dialog>,
<details>, <button> and forms that post before any script has run. A native
element ships its semantics for free.

The Combobox above is a good example. Every one renders a single role="status"
live region, already in the server HTML and empty until the field is used, so
the answers it announces have a stable place to go.

How do I know the keyboard handling works? The packages that need a hydrated
page have browser checks in pages/checks/. On every pull request, headless
Chromium presses the keys, moves focus, opens dialogs and toasts, and asserts
what happens, instead of trusting the markup. The repository also has 139 test
files (counted with find . -name "*.test.ts*").

Rendered on the server, then hydrated

A component touches window or document only inside an effect or an event
handler. So every one renders complete HTML on the server and hydrates in the
browser. The live guide itself is served that way, and it reads with JavaScript
off.

This matters more than it sounds. A page that shows its content before the
JavaScript arrives is faster for the visitor and easier for a search engine. And
a component that only works after hydration usually hides a bug that shows up on
a slow phone.

Colours, radii and fonts are CSS custom properties, so an app restyles
everything by setting variables instead of forking the CSS. Layout goes through
Page, Section, Stack, Cluster and Grid, and no component carries an
outer margin. The guide's header switches between light and dark and changes the
accent colour live, so you can see the tokens at work.

What is in the ten packages

Every package is published on JSR under @spy4x/preact-*, all at the same
version, so a caret range always resolves to a set that was published together.

Package	What it holds
`@spy4x/preact-ui`	the component set: layout, buttons, tables, dialogs, forms
`@spy4x/preact-theme`	design tokens, the Tailwind preset and the classes
`@spy4x/preact-icons`	the merged icon set, one component per glyph
`@spy4x/preact-charts`	server-rendered charts with tooltips
`@spy4x/preact-system`	app-level pieces: auth form, calendar, shells, SEO head
`@spy4x/preact-crud`	a list and editor scaffold for one collection
`@spy4x/preact-map`	a map on Leaflet
`@spy4x/preact-signals`	stores and state helpers; no components
`@spy4x/preact-cn`	class-name join with Tailwind conflict resolution
`@spy4x/preact-ui-guide`	the live component catalogue, mounted in one line

The guide's overview counts 81 components and 120 icons across them today.

Where it came from

The components were extracted from real products, so I stop rebuilding the same
pieces for the next one. My SaaS template
already builds its signed-in layout on Shell from @spy4x/preact-system and
its styles on @spy4x/preact-theme. This site is next: it still has its own
components, and replacing them with the library is an open issue.

The design is not mine. The design system, the component styling and the
original markup are by Eirene
(isorokina.com). She designed it and built the
original pages the components were first extracted from. What I added is the
JavaScript: the Preact and signals implementation, the interactivity, server
rendering, tests, packaging and documentation.

Helpers with no UI, like dates and validation, come from my other library,
ts-libs, under the same @spy4x scope on JSR.

Try it in a minute

Open the live guide. Every
component runs there with its code one click away, so you can try one before you
install anything.

When one looks right, add the package:

deno add jsr:@spy4x/preact-ui

And render it:

import { Badge } from "@spy4x/preact-ui/badge";

<Badge text="Active" color="green" />;

One honest catch: the components render Tailwind classes against the compiled
stylesheet from @spy4x/preact-theme, and JSR cannot export a CSS file. So the
stylesheet takes a short build script instead of a plain @import. The theme
package's README has the recipe, one short TypeScript file.

The repository also has an llms.txt, so a coding agent can read the whole
component surface in one file.

What is not done yet

I mark it beta on my site, and here is why. The version is 1.2.0 and it follows
semantic versioning since 1.0.0, so a breaking change bumps the major number.
But:

No screen reader has been run against it yet. The browser checks prove the markup and the order in which the page changes, not what a screen reader actually speaks. That work is an open issue.
Only Deno is tested. The packages are standard ES modules with no Deno-only API, and a Vite app can use them through @deno/vite-plugin. Running them under Node or Bun has not been tried.
It is Preact and Tailwind only. If your app is React, or you don't use Tailwind, skip it.
Some components are deliberately not built. Carousel, Accordion, Drawer, a rich-text editor and a tree view were considered and turned down: nothing I run needs them, and some would need a large third-party piece I don't want. The reasons are written down in the repository.
Nothing in CI enforces the no-library rule. A pull request could add Radix and every check would pass. Review holds the rule, and the repository says so instead of pretending a check exists.

What next?

Open the live guide, press Tab
through a dialog, and see if it behaves the way you expect. If something is
missing or broken, open an issue on
GitHub. And if the library looks
useful, a star helps other Preact developers find it.

Building a product and want its UI layer owned like this, instead of rented from
a library? That's my day job: see
how I build a SaaS MVP.

First published on antonshubin.com.

Opus 5.5 vs Sonnet 5: the pricier model wrote my code for about half the cost

Anton Shubin — Sat, 26 Sep 2026 05:54:16 +0000

Opus 5.5 lists at twice the price of Sonnet 5. In my coding agents it cost about
half as much per line of code. It also replaced Fable 5.1 as my code reviewer,
at about a third of the price.

This post is the data behind that switch: five days of my own Claude Code
transcripts, priced at API list prices, with the parts that are proven kept
apart from the parts that are only likely.

How I run agents

I work in waves. A lead model reads a list of GitHub issues and splits them into
lanes that touch different files. Each lane gets an implementer agent that
writes the code in its own git worktree and opens a PR. A separate reviewer
agent then checks every PR: it runs the tests, breaks the code on purpose to see
whether a test goes red, and checks the PR description's claims. Nothing merges
until a reviewer passes it. A failed review ("needs-fix") goes back to the
implementer for another round.

Between September 20 and 25 that produced 203 implementer PRs and 411 reviewer
agents across four models. I pay a flat subscription, so the dollars below are
API list prices, used as a measure of how much of my usage limit each agent
burned.

Model	Input $/M	Output $/M	Cached read $/M
Sonnet 5	2	10	0.20
Opus 5	5	25	0.50
Opus 5.5	4	20	0.20
Fable 5.1	10	50	0.25

The last column is the one that matters, and the next section shows why.

Where the money actually goes

An agent doesn't pay for its work once. Every step is a new API call that sends
the whole conversation again: the brief, every file it read, every test log.
Most of that comes from the prompt cache, so each call is cheap, but an agent
makes hundreds of them.

In one six-hour window on September 24, my agents used about $593 at list
prices. 68% of that was cached reads, 22% cache writes and 10% output.
Across 57 agents, cost tracked "number of calls × average context size" almost
perfectly (correlation 0.99). The worst offenders were Sonnet implementers that
ran 400–600 calls while their context grew to 600–970K tokens, because nothing
compacted it before about 967K. Every one of those calls re-read the whole
thing.

So the price per token matters less than you'd think. What matters is how many
steps an agent takes and how much it carries through each one.

Cached reads cost the same $0.20 per million tokens on Opus 5.5 and Sonnet 5.
Only input, output and cache writes cost twice as much on Opus. For my Sonnet
implementers, cached reads were about three quarters of the bill (the median
lane), so the same call costs only about 25% more on Opus 5.5, not twice as
much.

Implementers: fewer steps beat a cheaper token

Opus 5 only ran on September 20–21 and Opus 5.5 only on September 23–25, so each
is compared with Sonnet 5 on the same days:

Days	Model	Cost per 100 changed lines	API calls per 100 lines
Sep 20–21	Sonnet 5	$1.57	30
Sep 20–21	Opus 5	$2.45	15
Sep 23–25	Sonnet 5	$2.13	38
Sep 23–25	Opus 5.5	$0.39	6

"Changed lines" is additions plus deletions in the PR. The median PR was the
same size for Sonnet 5 and Opus 5.5 (484 and 504 lines), so Opus isn't winning
by writing more lines. Over all five days, per 100 changed lines, Opus 5.5 made
6 times fewer calls than Sonnet, read 10 times less context and wrote 3 times
less output.

Opus 5 was not wasteful; its price was. Its prices are exactly 2.5 times
Sonnet's on every kind of token, so at Sonnet's prices it would have cost $0.98
per 100 lines against Sonnet's $1.57. Opus 5.5 keeps that efficiency and drops
the price.

The raw gap overstates it

The table says Opus 5.5 cost a fifth of Sonnet. That isn't a fair comparison,
because I chose which tasks went to Opus, and I gave it mostly authentication
and crypto work. So I compared units of work of the same size and kind, in the
same repository and the same session. Measured that way, Opus 5.5 cost about
0.45 times what Sonnet did (plausible range 0.29–0.71).

That's still a big saving, and the more interesting part is where it comes from.

The first draft costs about the same. Up to the first review verdict, Opus
5.5 cost about 0.77 times Sonnet, and that range includes equal cost. Opus did
bundle its work into fewer, longer shell commands: a median of 31 calls before
the first review, against Sonnet's 97.

The saving is in the fix rounds. In the September 24 window, fix rounds were
about 71% of implementer spend. A Sonnet implementer that had already grown a
900K context paid $5.60–6.40 for a small last-round fix, because it re-read
everything to make it. Opus carried a smaller context (a median peak of 170K
against Sonnet's 246K), and in the 5 Opus lanes of the fair split I describe at
the end it needed a median of 2 review rounds against Sonnet's 3.

Most PRs fail their first review

On ordinary code, most PRs from every model failed their first review. Sonnet 5
and Opus 5 passed 12–20% of the time. In one six-hour window on September 24,
all 20 PRs that changed production code failed their first review.

Opus 5.5's raw first-review pass rate looks great: 10 of 18. But almost all of
those passes were auth work that I had routed to Opus and that Fable reviewed.
On other code, Opus 5.5 passed 1 of 7, which is too few to say anything. Look at
why PRs fail, and the model matters less: at least 7 of those 20 failures were
tests that stayed green on broken code, or a PR description that claimed
something untrue. I don't expect a smarter model to fix that, so I changed the
process instead; it's too early to know whether that worked.

More reasoning effort cost more and bought nothing

Until this week, my implementers ran at whatever effort their lead used, so the
past lanes cover several levels:

Implementer	Effort	Cost per 100 changed lines	Passed first review
Sonnet 5	medium	$1.72	8 of 64 (12%)
Sonnet 5	high	$2.52	9 of 53 (17%)
Sonnet 5	xhigh	$2.56	1 of 13 (8%)
Opus 5.5	medium	$0.39	9 of 16

Sonnet at high effort cost 35–51% more per line than at medium, with no clear
gain in review results. Opus 5.5 did its auth and crypto work at medium. This is
observational (repositories ran at different efforts), so it's a signal, not
proof. It was enough to stop me guessing effort up front.

Reviewers: Opus 5.5 against Fable 5.1

On the same kind of PR in the same days, with both priced at Opus 5.5's rates, a
review round cost $1.36 on Opus 5.5 and $1.50 on Fable 5.1: about the same
amount of work. At real list prices, Fable cost about 2.7 times more, and it was
slower (a median of 9 minutes a round against 6.5).

Fable wasn't stricter either. On Sonnet-written code in the same days, it
blocked 17 of 19 first submissions, and Opus 5.5 blocked 74 of 92. That is no
real difference.

On the four PRs that both reviewed at the same time, each caught security bugs
the other missed. One was a delete path that followed symbolic links: Fable
caught it, and the Opus review running in parallel did not. So neither reviewer
is complete on its own. Instead of paying 2.7 times more for a second opinion, I
added that class of bug to the reviewer's checklist.

What I changed

Opus 5.5 implements and reviews every diff. Fable stays paused.
Medium effort by default. Reviews of production code run at xhigh, and reviews of auth, crypto, secrets, money, deploys and data migrations run at max. An implementer only moves up to xhigh for one fix round, when a PR's second failed review names a real behaviour defect.
Compact at 400K tokens instead of about 967K. The single largest saving in the analysis: it caps how much every call has to re-read. Reviewers, which peaked at 277K in the window I measured, never hit it.
A 1-hour cache for reviewers. Re-reviews usually arrive after the default 5-minute cache has expired, so the reviewer paid to rebuild its whole context.
Proof for every test. Each test a PR adds or changes needs a line in the PR body naming the code change that turns it red. A PR without those lines goes back before any reviewer spends a token on it.

What this doesn't prove

It isn't a controlled experiment. I chose which tasks went to Opus, the sample
is small (19 Opus 5.5 PRs), and list prices are a stand-in for subscription
usage. I started a fair split, with every other lane on Opus 5.5 regardless of
the task, and stopped it early: the like-for-like comparison and the token
counts pointed the same way. Opus 5.5 was cheaper, probably around half, and at
worst no more expensive.

One gap favours Opus in these numbers. In at least 3 of the 8 Opus PRs that
failed their first review, the lead agent made the fix itself, so that fix's
cost is missing from Opus's total. That happened in only 1 of 89 Sonnet cases.

The lesson I'd keep even if the model prices change next month: in agent work,
you pay for steps and context, not for tokens. Measure calls and context per
unit of work, and the right model is usually obvious.