Why Kin Store?
Kin Store starts from one constraint: the smallest set of ideas a state library actually needs, and nothing past that.
What that meant in practice
Three primitives came out of that constraint: createStore, withPlugins, and derive.
| Primitive | What it does |
|---|---|
createStore | The irreducible floor. get · set · subscribe. Nothing else. |
withPlugins | Opt-in structure: methods, reducers, middleware, lifecycle hooks, namespaced plugins. |
derive | Lazy, dependency-tracked, read-only views composed from one or more stores. |
None of them carry a framework's worth of internal bookkeeping. A bare createStore is a value and three methods, nothing else. Whatever structure you add on top, methods, reducers, middleware, only exists because you .use()'d a plugin for it through withPlugins; the store doesn't route everything through a slice and a dispatch table by default.
Nothing runs through a proxy or a full reactive graph either. A bare store costs exactly what get/set/subscribe cost, and each plugin you layer on adds its own cost on top, stacking rather than multiplying against what was already there.
Type inference comes along on top of that: reducer arguments, dispatch calls, and plugin methods are fully inferred, so you're not hand-annotating what the compiler already knows.
Curious how this holds up against Redux, Zustand, Jotai, or MobX in practice? See the full comparison — line-by-line, with the tradeoffs named directly.
Next
- Getting Started — install and write your first store.
- Design Principles — the reasoning behind each API choice.