UI libraries
How to choose a UI library: five measured criteria
Licence, dependencies, accessible states, maintenance and exit cost: five criteria you can check today, with the commands and the exact places to look.
Key points
- Read the licence on the single record, not on the library home page.
- Stars measure attention, not maintenance: read dates and releases.
- Exit cost depends on the install type: an npm package or code in your repository.
You choose a UI library with five checkable criteria: licence, dependencies, accessible states, maintenance and exit cost. Popularity is not one of them.
1. Licence: read the record, not the home page
The licence decides whether you can ship the component in a closed product. shadcn/ui, MUI, Mantine, Radix UI and Base UI all declare MIT in the LICENSE file of their repository. Check the licence of the single record, because a catalogue can mix MIT, Apache-2.0 and custom terms. Source: the LICENSE file in each repository, read on 1 November 2026.
npm view @mui/material version license dist.unpackedSizeThe command prints version, licence and unpacked package size. That is not the bundle size, but it is a comparable first filter between candidates.
2. Dependencies: how much you install for one button
Open the library package.json and count the direct dependencies. A headless primitive with two dependencies is easier to replace than a framework with twenty. Check the peers too: a peer on a React major your project does not run yet blocks the upgrade before any code changes.
3. Accessible states: the preview is not enough
Test with the keyboard: Tab reaches the control, focus is visible, Enter activates, Esc closes. Then look for disabled, loading and error states in the code, not only in the preview. The 12-point checklist is in accessible React components.
4. Maintenance: dates, not stars
Read the latest release, the date of the last commit and how many issues closed in the last 90 days. Stars measure attention, not maintenance. Source: the Releases page and the repository history, read on 1 November 2026.
5. Exit cost: is the code yours, or does it stay in the package?
An npm library stays a dependency: one command updates it, but an API change forces you to adapt. A component copied from a registry lives in your repository: you edit it, but updates become a manual diff. The comparison of the two approaches is in copy-paste or headless.
The five criteria in one table
| Criterion | Question | Where to check | Warning sign |
|---|---|---|---|
| Licence | Can I ship it in a closed product? | Repository LICENSE file and the npm license field | Custom licence or none |
| Dependencies | How much do I install for one button? | package.json and npm view output | Peers that block upgrades |
| States | Do focus, disabled, loading and error exist? | Preview, code and keyboard | Only the happy path in the code |
| Maintenance | When did the last release ship? | Releases page and repository history | Last commit over 12 months ago |
| Exit | Does the code stay mine if I switch? | Install type: npm or registry | Closed API and no migration path |
The limitation of the catalogue
EneUI counts records, not quality. A library with 5,000 components can still ship missing focus rings and inconsistent names; the catalogue does not know. Use the numbers to shorten the list, not to close the decision.
Where to continue
For the vocabulary read UI kit, component library or design system; the measured comparison is in React libraries 2026. In the catalogue you can start from 111,985 components, open a record such as Keyline and compare a category such as chart.
Frequently asked questions
Which criterion matters most?
Licence comes first: if you cannot use the code in production, the other four criteria do not count. Exit cost comes next, because it is the one you pay when the library changes.
Do GitHub stars count in the choice?
No. Stars measure attention, not maintenance. Read the date of the last release and the rate at which issues close.
Are ready-made components better than headless primitives?
If you have to ship a screen within a week, ready-made components save time. If the design system is the product, headless primitives keep control of markup and style, at the cost of more work.
How do I check accessibility in ten minutes?
Move through the page with Tab and Shift+Tab: focus must be visible and in the right order. Then open the code and look for disabled, aria-invalid, role and Esc handling. If one of those states is missing, the preview proves nothing.
Is a library with 10,000 components better than one with 50?
No. The number measures catalogue coverage, not consistency. A small library with a stable API and complete states costs less than a large one you have to clean up.