Libraries, Frameworks and Toolkits
Date: 2026-08-18
A library you call; a framework calls you. That single distinction — who owns the control flow — is what separates a dependency you can remove in a sprint from a commitment that takes a replatform to undo. Every other label here is a position on that axis plus a claim about scope.
The load-bearing distinction
LIBRARY FRAMEWORK
your code the framework
↓ calls ↓ calls
the library your code
↓ returns ↓ returns
your code continues the framework continues
YOU own the flow. IT owns the flow.
the library is a tool you pick up. your code fills slots it defined.
This is inversion of control, and the old joke names it exactly: don’t call us, we’ll call you.
The practical consequence is reversibility. You can stop calling a library. You cannot stop a framework calling you without removing the framework — which means removing the routing, the build, the conventions and the file layout it imposed.
what it costs to remove
a utility library an afternoon date-fns, lodash
a UI library a project React → Vue
a state manager a project
a framework a replatform
a platform a business case
The bottom two rows are the ones with names in this vault: swapping a framework is a replatform, and leaving a platform like Shopify is a commercial decision before it’s a technical one.
That table is the whole reason the distinction is worth caring about, and it’s the version to use in a meeting. “Is this a framework?” is a question about what it will cost to change your mind.
The categories as actually used
| Who calls whom | Scope | Examples in this vault | |
|---|---|---|---|
| Library | You call it | One job | React, date-fns |
| Framework | It calls you | Everything — routing, build, deploy | Next.js, Laravel, Rails |
| Meta-framework | It calls you | A framework wrapped around a UI library | Next.js on React, Nuxt on Vue, React Router framework mode |
| Toolkit / SDK | You call it | One vendor’s service | Hydrogen (new), Stripe, AWS |
| Runtime | It runs you | Where code executes | Node, Deno, Bun, Workers |
| Build tool | You configure it | Transforms your source | Vite, esbuild — Build Tools |
| Platform | You rent it | A service with an account | Shopify, Vercel — Platforms |
Meta-framework is the one worth naming, because it’s most of what people actually adopt. Next.js is not an alternative to React — it’s a framework that assumes React and adds everything React deliberately left out. So “we use React” and “we use Next.js” are statements about different layers, and only the second is a commitment.
Why the labels are unreliable
Three reasons, and all three are live right now.
1. Things move between categories. Hydrogen was a complete framework and is becoming a toolkit — same name, opposite answer to “who owns the control flow”. Shopify’s own framing is the clearest statement of why anyone would do that:
“A framework is a strong opinion about everything: routing, data loading, rendering, deployment. That opinion is a gift when it matches how you want to work, and a tax when it doesn’t.”
2. One package can be several things at once. React Router is the standing example: declarative mode is a library, data mode is a library with opinions, framework mode is a framework. Same install, three levels of commitment — and the docs use one name for all of them — Reference - React Router.
3. “Framework” sounds more serious. There is a marketing incentive to claim the word, and no incentive to give it up. Read the architecture rather than the homepage.
React is the instructive edge case. It calls itself a library and is one by the control-flow test — you call createRoot, you decide when to render. But hooks constrain how you write functions, the rules of hooks are enforced by a linter, and reconciliation decides when your code runs. In practice it sits between the two, which is why the ecosystem needed meta-frameworks to supply the rest.
The pendulum
The industry swings between bundling everything and unbundling it, and both swings have the same cause: the previous position’s cost became more visible than its benefit.
BATTERIES INCLUDED UNBUNDLED
one decision, everything works keep your stack, add what you need
fast to start slower to assemble
consistent across a team consistent with what you already had
the tax: you inherit opinions the tax: you own the integration
you disagree with, in areas you between the parts
never wanted to think about
That integration cost is a real, recurring line rather than a one-off — Integration Patterns.
Neither is correct in general. The useful question is narrower: is the opinionated part the part I actually care about? Shopify’s answer for Hydrogen was that routing was never their advantage and the commerce primitives were — so they kept the second and dropped the first.
What to ask of any tool
Four questions, in order, and none of them are “is it a framework”:
- Who owns the control flow? Do I call it, or does it call me?
- What would removing it cost? The table at the top
- Which of its opinions am I buying, and do I want them? A framework’s value is its opinions; if you disagree with them you’re paying a tax for a gift
- What does it assume underneath? A meta-framework assumes a UI library assumes a runtime. Adopting the top of that stack commits you to all of it
The hiring question is downstream of all four. “We use React” is a large talent pool; “we use React Router framework mode on Oxygen with Hydrogen” is a specific person you have to find or train — Choosing a Framework.
Where it interacts
- Choosing a Framework — the decision this supplies the vocabulary for
- Coupling and Cohesion — inversion of control is a coupling decision, and the removal costs above are what that coupling is worth
- Abstraction and Leaky Abstractions — a framework is a large abstraction, and it leaks in the usual ways
- Composable Commerce — the same bundled-versus-unbundled argument, one layer up at the vendor level