Docs / Why Vanilla
An honest account of what copy-paste gives you, and what it costs.
No runtime. A KATA page ships the HTML, CSS and JS you can read in the tab next to this one — nothing transpiles, nothing hydrates, and the dependency list is empty, so there is nothing to audit, patch or be broken by. The code is yours in the plainest sense: fork a part, rename its classes, delete the half you do not need. It will still be running, unchanged, in ten years, because nothing underneath it can be deprecated.
This is also why AI tools are good at KATA: a part is a complete, self-contained answer in one context window. The registry and llms.txt exist so the model copies the mold instead of improvising one.
No components in the framework sense: no props, no reactivity, no tree-shaking. State that spans many parts — a cart, a multi-step wizard with shared data — is yours to wire, and past a certain size a framework earns its keep. KATA’s bet is that most pages are not that size: they are forms, tables, dashboards and marketing sections, and for those the framework was never the point.
The honest line: if your app is a document with behavior, vanilla wins. If it is a program with a document attached, use the framework — and KATA’s tokens and CSS still drop into it unchanged.
A package makes the library’s roadmap your roadmap: upgrades, breaking changes, abandonment. Copied code has no roadmap. shadcn proved the model for React; the trade is the same in vanilla — you own the code, including its bugs, and in exchange nobody can take it away, sunset it, or put it behind a pricing page.
Getting Started · Theming · Dark Mode · Accessibility · Installation · JavaScript · Guide: Building a Dashboard · Guide: Building a Settings Page · Guide: Building a Pricing Page · Guide: Sign-in & Account Pages · The Mold · Anatomy of a Part · Coming from Tailwind · FAQ · Changelog