Why Granularity
What can be checked here — and what you should hold against us.
Every claim on this site is either a number taken from a build or a link to the place where the rule is written. This page collects both, and then says plainly where the project is weak.
What can be checked
- Import granularity
136 export paths: a component, a composable or a single directive, each with its own graph.
Check it yourself: Build the app twice — with one component and with two — and compare the emitted bundles. The difference is the real price of the second component.
npx vite build && du -h dist/assets/*.js- Runtime dependencies
0 in the core. The only required peer is @floating-ui/dom, and it stays in your lockfile rather than inside the package.
Check it yourself: Read the manifest of the package you are considering — dependencies, not devDependencies.
npm view <package> dependencies- Token system
197 tokens as named roles in both themes, published as typed data and as CSS custom properties.
Check it yourself: Ask two questions: is there a list of roles at all, and can a role be changed without touching component sources.
- Server rendering
Every component renders on the server and hydrates without mismatches; the contract is written down and tested on a stand.
Check it yourself: Look for a page that says what happens on the server, not for the word “SSR” in a feature list.
- Accessibility
A keyboard contract per component, WAI-ARIA APG patterns, contrast checked by a gate in both themes.
Check it yourself: Open the component you need and try it with the keyboard alone. Documentation claims are cheap; Tab and Esc are not.
- TypeScript
Types per subpath, generated web-types for JetBrains IDEs, props and events typed from the source.
Check it yourself: Import one component in a strict project and see whether the editor knows its props without extra plugins.
- Licence
Apache-2.0 with an ethical use clause — source-available, not OSI-approved. Named on every page that matters.
Check it yourself: Read the LICENSE file, not the badge in the README.
- Support model
One maintainer, no company behind it, no paid support. Version 0.41.0 — before 1.0 breaking changes live in the changelog.
Check it yourself: Look at the issue tracker: how long an answer takes and who gives it.
Where this project is weak
A weakness found by the reader costs more trust than one named out loud. These three are named on purpose.
Immature
Version 0.41.0, before 1.0. Breaking changes happen and live in the changelog; there is no migration guide yet because there has been nothing to migrate from.
One maintainer
No company behind it, no paid support, no service-level promise. What holds quality instead is machinery: twenty-seven build gates that fail the build rather than file a warning.
A non-standard licence
Apache-2.0 with an ethical use clause. That makes it source-available rather than OSI-approved open source, and a licence register may treat it as unknown. For the overwhelming majority of commercial uses there is no restriction at all — but read it before you plan around it.