Starwind UI: source-owned Tailwind components with a shared runtime behind Astro, React and Vue
55 framework-portable UI components for Astro, React, and Vue. Install accessible Tailwind CSS components as source you own, backed by a shared framework-neutral Runtime.
At a glance
- What is it?
- Starwind UI ships 55 Tailwind CSS components as source you copy into your project, plus a framework-neutral Runtime that generates Astro, React and Vue 3.5 beta adapters. The Vue side is still a public beta with an unstable API, and the Styled Image component exists only for Astro.
- Who is it for?
- Adopt Starwind UI if you are on Astro or React, want the component source inside your own repository, and are willing to track upstream diffs by hand when a component changes. Do not adopt it if you need a stable Vue API today, or if you want a dependency you can upgrade with a single version bump.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Starwind UI targets: component code you cannot edit
Most component libraries hand you an npm package. The markup, the styles and the keyboard handling all live behind an import boundary, and when a design calls for a different focus ring or a different transition, you fight the library instead of editing it. Starwind UI takes the opposite position. The README states its first selling point as "Own Your Code", with styled components living in your project "where you can understand and customize them". The CLI adds only the components you ask for.
The audience is narrower than that pitch suggests. The README calls the project "Astro-first", and the stable install path covers Astro and React. Vue arrives through a separate package, @starwind-ui/vue@beta, which the README says targets Vue 3.5 and is tested against Vite Vue, Astro Vue, Nuxt 3 or 4, Laravel with Inertia Vue, and Quasar Vite SPA/SSR projects. If your stack is Svelte, Solid or Angular, nothing in the supplied material describes an adapter for you.
The second problem is behavioural duplication. A dropdown that closes on Escape and traps focus correctly is the same dropdown in every framework, but the code that implements it is usually rewritten per framework. Starwind UI separates that behaviour from the framework markup, which is the design decision the rest of this review turns on.
How the Runtime, the adapters and your components fit together
The README includes a flowchart with four layers. Your application renders Starwind components, which the README describes as "Tailwind CSS + framework markup" that you own. Those components call a framework adapter. The adapter calls the Starwind Runtime, described as "shared accessible behavior". The Runtime talks to browser APIs and the DOM.
The direction of that flow matters. Accessibility logic, focus handling and DOM behaviour sit in one framework-neutral Runtime. The adapter is the translation layer that exposes the Runtime through the idioms of a given framework. The component file in your repository holds the Tailwind classes and the markup structure, and delegates behaviour downward.
For Vue, the README is specific about what idiomatic means: adapters use "v-model arguments, matching update:* events, and normal detailed event listeners". That is a real commitment to Vue conventions rather than a thin wrapper that emits raw DOM events and leaves you to wire reactivity yourself. The README points to docs/portable-runtime/README.md for "the current implementation details", which is where you would go to check how the Runtime is packaged and whether it ships as a runtime dependency or is inlined.
The README does not state how many adapters exist beyond Astro, React and Vue 3.5 beta, nor whether the Runtime is written as a separate published package. Those are questions for the portable-runtime document, not the README.
Installing: init, add, and the framework flag
The stable path is two commands. Initialize an Astro or React project with npx starwind@latest init, then add components with npx starwind@latest add. The README does not show the interactive prompts or the flags for the add command, so the selection mechanism is not confirmable from this material.
Vue takes a different route. You install the beta package and Vue 3.5 alongside it, then run init with an explicit framework flag:
npm install @starwind-ui/vue@beta vue@^3.5 npx starwind@latest init --framework vue
That --framework vue flag is the one concrete config key visible in the README. It implies init detects or asks for a framework by default and that the flag overrides detection, but the README does not spell out the detection rules.
The README also notes that the main package lives elsewhere in the repository, at starwind-ui/cli, so npx starwind resolves to a separate CLI package rather than the component set. The repository topics list mcp and agent-skills, and the AI integration section links a Starwind Skills page, an MCP server page, llms.txt and llms-full.txt. Those are documentation surfaces for tooling, not runtime features, but they are part of what the project ships.
Where Starwind UI breaks down
The Vue adapter is the clearest limitation, and the README states it without hedging. The Vue API "can change during the 0.x series". Beta feedback goes to the issue tracker. If you are building a Nuxt or Laravel Inertia Vue product with a release schedule, a 0.x API that reserves the right to change is a maintenance liability you are accepting on purpose.
The Styled Image component is Astro-only, per the README. That is a genuine feature gap rather than a documentation omission, and it means a component set advertised as portable has at least one component that is not.
Source ownership cuts both ways. Because the components live in your repository, upstream fixes do not reach you through a version bump. You either re-run the add command for that component and reconcile the diff, or you patch your copy and diverge. The README does not describe an update or diff command, so the reconciliation workflow is not documented in the supplied material. On a project with fifty components and active upstream development, that is the cost you pay for the ability to edit them.
The README also does not describe a theming or design-token layer, a component count breakdown, or browser support targets. The 55-component figure comes from the repository description, not from a list you can audit in the README.
How this differs from shadcn/ui
The README positions Starwind UI as offering "Starwind/shadcn-style ergonomics", which makes the comparison fair. Both distribute components as source rather than as an installed package, and both rely on Tailwind CSS. The difference is what happens to behaviour.
In the shadcn/ui model, each component carries its own behaviour, and the React implementation depends on Radix primitives. The component you copy is the whole thing. Starwind UI splits that: the component you copy is markup and Tailwind classes, and the accessible behaviour lives in a Runtime reached through a generated adapter. That split is what makes the same component definition usable from Astro, React and Vue. It also means the source you own is not self-contained. Reading a Starwind component file will not show you the keyboard handling, because that code is one layer down.
For an Astro project the trade is favourable, since Astro components have no equivalent of Radix and behaviour has to come from somewhere. For a React-only project, adding a Runtime and an adapter layer to get behaviour that Radix already provides is extra indirection, and you should decide whether portability you will never use is worth it. The README does not argue this case either way.
Licence and maintenance cost
Starwind UI is MIT licensed. That permits commercial use, modification and redistribution, and it means the component source you copy into your repository carries the same permissive terms. The README does not mention an attribution requirement beyond the licence file itself, and nothing in the supplied material describes a paid tier, a hosted service or a commercial exception. This is a description of what the licence permits, not legal advice; check the LICENSE file in the repository before you rely on it.
Maintenance splits into two tracks. The Runtime and adapters are ordinary dependencies: you follow releases, and the project has published v3.3.0, v3.3.1 and v3.3.2 within roughly two days of each other in September 2026, which suggests a fast patch cadence. The components in your repository are not dependencies. They are your code now, and they age independently of the Runtime they call.
That second track is the one to budget for. A Runtime change that alters expected DOM structure or event names can leave a component you copied months ago out of step with the adapter it depends on. The README does not describe a compatibility contract between the Runtime and previously generated components, so treat that interface as the thing to watch. The Vue 0.x caveat compounds it: a beta adapter plus a copied component plus a shared Runtime is three moving parts on the Vue path, against two on the Astro and React paths.
Editorial conclusion
Adopt Starwind UI if you are on Astro or React, want the component source inside your own repository, and are willing to track upstream diffs by hand when a component changes. Do not adopt it if you need a stable Vue API today, or if you want a dependency you can upgrade with a single version bump. Before committing, run npx starwind@latest init in a throwaway branch, add one interactive component, and check the generated adapter against the Runtime documentation in docs/portable-runtime/README.md.
Community notes