Also available in Español
The Problem
A team adopts a component library. Buttons look great. Cards are consistent. Modals behave the way modals are supposed to behave.
Six months in, someone still can't confidently predict which of two conflicting rules will win on a given page. Not because the library did a bad job — it did exactly what it promised. It just never promised anything about that.
Why the Problem Exists
Libraries get evaluated on the quality and completeness of what they ship: how many components, how consistent they look, how well the documentation covers them. Those are reasonable things to check. None of them touch precedence, boundaries, or resolution order.
A library can score well on every axis anyone thought to check and still leave the cascade exactly as unmanaged as it was before the library arrived. That's not a hidden flaw someone failed to catch. It's a category the evaluation never asked about in the first place, because "how good are the components" and "what does this system guarantee" are different questions, and only one of them tends to get asked out loud.
The First Principle
A library is a collection of components. An architecture is a collection of guarantees.
A library answers "what can I use." An architecture answers "what can I rely on." A team can have an excellent, well-documented answer to the first question and no answer at all to the second, because nothing about owning a large set of components implies anything about how those components resolve against each other, or against anything else already on the page.
Demonstrating the Principle
.card-title { font-size: 1.25rem; }
.text-lg { font-size: 2rem; }
Both from the same library. Applied to the same element, one of them wins — decided by ordinary specificity, source order, whatever's actually present in the stylesheet that day. The library never declared an answer either way. It shipped two components and left their relationship to each other entirely unaddressed, because addressing it was never part of what "library" meant.
quell as the Case Study
quell isn't a component library with architecture bolted on afterward. The guarantees come first; the components are the visible surface of them.
The Broader Lesson
The same confusion shows up anywhere abundance gets mistaken for structure. A well-stocked toolbox isn't a design for how the tools are meant to be used together, no matter how many tools it holds or how well each one is made.
That's the distinction the final two articles keep building on.
Top comments (0)