Build1 distinct publisher3 min readPublished
A maintainer tried to disprove his own README and published the checks that did it. The numbers are the only part a consumer can actually use.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Sixty-two to one is what that size budget actually asserts. Take 40 kilobytes as 40,000 bytes and a 641-byte single-component import is about 1.6 percent of the figure it is measured against [5]. The post does not spell out what the larger number covers, and the ratio is not the interesting part anyway. The interesting part is that both numbers sit in CI, so a refactor that quietly re-couples Btn to the rest of the kit fails the build instead of surfacing in someone else's bundle report months later [4]. That only works because each component ships as its own entry point in the first place [3].
The same pattern runs through the Server Components work, and the arithmetic there is blunter. Roughly 64 components call hooks and roughly 36 carried "use client" [9]. Subtract and about 28 components were calling hooks with no directive at the first run, which is a floor rather than a count: any directive sitting on a component that never calls a hook widens the gap [10]. The find was a list diff, not a code review. The react-hook-form wrappers all had the directive, while the Formik family, same author and same shape, had it on none of them despite every one calling useField() [8]. Reading the files carefully would not have caught that [9].
Burger is the case worth stealing. It holds no state, and open and setOpen arrive as props, so the gut call is server-safe [11]. But the rule has two limbs, calling a hook and wiring a DOM event handler in your own JSX, and its onClick trips the second [6][11]. Then the checker's own blind spot: the glob read only .tsx files, so useCombobox.ts shipped as a public import with no directive and nothing looking at it [12].
The deliberate exception is the honest part. Progress and Skeleton spread {...rest} from loosely typed props onto their host element, so a consumer could pass an onClick through, and the maintainer left them marked rather than trimming them to the strict rule, on the ground that an extra client boundary is cheap while a missing directive breaks a click handler silently in production [13][14]. That is written down as unresolved rather than closed [14].
Accessibility is where the layering matters most. Every component already had a jest-axe unit test, a per-component property that was being read as a kit-level one [15]. Rendering the real stories in a live Chromium browser produced 29 violations across 16 story files, about 1.8 per affected file, none of them reachable by a test that renders one component alone [16][17][18].
All of this is one maintainer's self-reported CI output on a kit pulled out of a coworking site he built, published on dev.to and unverified by anyone else [1][19]. It is still a better disclosure than the adjectives, because each number names the check that produced it and the build that fails without it.
Ranked by verification strength, evidence, and original report placement.
The author added size-limit to CI so the tree-shaking claim has to keep being true, reporting 641 bytes vs 40 kilobytes; if a refactor accidentally makes Btn drag in half the kit, the build fails instead of the problem surfacing later as a bundle-size complaint.
The author found the gap by grepping the roughly 64 components that use hooks against the roughly 36 that already had the directive and diffing the two lists; he states that reading eight files carefully would not have found it.
The browser-based run found 29 real violations across 16 story files, none of them caught by the existing unit tests, because a unit test only ever renders one component in isolation and never two composed the way an actual page does.
The author open-sourced brightframe, a React UI kit pulled out of a real coworking site he built called LAN.
The README made three claims the author typed confidently early on, "Tree-shakeable", "Server Components-safe" and "Accessible", and he later sat down and tried to prove himself wrong on each.
Every component ships as its own entry point, for example: import "brightframe/tokens.css"; import "brightframe/Btn.css"; import { Btn } from "brightframe/Btn".
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific, checkable numbers from one self-reporting maintainer
The claims are unusually concrete for a project post: named script paths, named tooling, and hard counts (641 bytes vs 40 kilobytes, ~64 versus ~36 components, 29 violations across 16 story files), several of them enforced continuously in CI rather than measured once. But every figure comes from the maintainer's own tooling in a single first-person article, with no independent reproduction, no linked CI output, and no external audit, so the evidence is detailed yet wholly unverified.
One first-party deployment; no external uptake disclosed
The only usage evidence in the cluster is that the kit was extracted from and used in the author's own coworking site, LAN, and then open-sourced. No downloads, dependents, external consumers, forks, issues or third-party deployments are reported, and the accessibility layer was run for the first time the same week the post appeared.
Self-critical framing sits slightly below its own evidence
The post's rhetorical direction is deflationary: it exists to attack three README adjectives, and it publishes the failures those checks found — an entire wrapper family missing "use client", a glob that skipped .ts files, 29 accessibility violations, documentation examples nesting buttons — plus one item left deliberately unresolved. Claims are narrower than the tooling behind them and no market or superiority assertions are made, so the modest negative reflects understatement. It is held near zero rather than deeper because the reassuring numbers are still self-measured and adoption evidence is minimal against a broadly framed 'proof a UI kit owes its consumers' premise.
Maintainer promoting his own kit, partly offset by disclosed failures
The author is the kit's maintainer publishing on a developer platform where an engineering-credibility post also functions as distribution for a newly open-sourced library, and he explicitly positions it against the crowded field of interchangeable npm kits. That promotional incentive is real but tempered: the piece volunteers embarrassing defects, an unfixed glob, and a deliberately unresolved directive decision, none of which serve a pure marketing goal. No sponsor, employer, funding or vendor relationship is disclosed or implied.
Internally consistent single source, externally unchecked
The narrative is coherent, technically plausible, and specific about mechanism, tooling and file names, and the freshly published timestamp matches the described first runs — which supports moderate confidence in the account as told. What holds it near the middle is structural: one publisher, one author, no corroboration, approximate component counts, and no way for a reader to inspect the CI results or the repository state behind the figures.
build
A build-tool swap that took 70 days and 166 files, and the build was the easy part1 distinct publisher
build
Chess's one-game-a-day cap is a two-core bill, and WebAssembly moves it onto your laptop1 distinct publisher
build
The stroke width that never rendered: SVG attributes lose every cascade fight1 distinct publisher
build
The Escape-key listener you cannot fix with a dependency array1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 24, 2026