SV5UI: A Component Library for Svelte 5 That Carries You Past the Easy Part

Disclosure: I am the author of SV5UI. It is MIT-licensed and the source is on GitHub, so you can judge it for yourself.

The Easy Part and the Rest

Every application has a honeymoon. In the first week the screens are simple, the forms have three fields, and whatever UI library you picked makes you look fast.

It ends around month three. The forms now have twenty fields and conditional validation. Marketing has sent a brand palette and expects it everywhere. The ops team wants a table of four hundred thousand rows they can filter, edit in place and export. Someone wants a calendar where bookings are dragged from one afternoon to another.

None of that is exotic — it is simply what applications turn into. And it is the moment a UI library either keeps carrying you or quietly becomes the thing you work around, writing wrappers, forking styles, bolting on a second library with a different idea of what a modal should do.

SV5UI is built for that second phase. Anything can get you through the first one.

What It Is

A component library written natively for Svelte 5 — built on runes from the first line, not ported from an older API, because a library that fights the framework's reactivity model will fight you in every component you touch.

<script>
    import { Button, Avatar, toast } from 'sv5ui'
</script>

<Button variant="soft" color="primary" leadingIcon="lucide:edit">Edit</Button>
<Avatar src="/photo.jpg" alt="Jane" size="lg" />
<Button onclick={() => toast.success('Saved!')}>Save</Button>

Accessible behaviour comes from Bits UI and Vaul Svelte. SV5UI adds the styling, the theming system and one consistent API on top, in Tailwind CSS 4, typed strictly throughout.

Setup is three steps: install the package, import sv5ui/theme.css, and drop <ThemeMode /> into your root layout for dark mode. No provider to wrap your app in, no config file to write before you can render a button. Only Svelte 5 and Tailwind 4 are required — everything else the library brings with it.

Enough Components to Finish the Job

There are more than seventy, and the shape of the coverage matters more than the count.

Forms get the depth, because that is where applications live: text and number fields, tag inputs, searchable menus, file uploads, colour pickers, date and time controls, and a form layer that ties them together with validation. Around that sit the overlays, navigation, data display and feedback pieces — plus the ones a library is allowed to skip and which always become someone's week anyway: a rich-text editor, a command palette, an image cropper.

They behave as one library. Every component takes the same variant, color, size and ui props, so the second one you learn costs almost nothing and the fiftieth costs nothing at all. The live demo has all of them with working examples and prop tables.

Making It Look Like Yours

Sooner or later every project says the same sentence: it looks great, except it has to look like our brand.

If a library's only answer is "edit the component," you will edit forty of them, and from then on you maintain a fork instead of building a product. SV5UI answers at whichever level the request lands.

Round off one button:

<Button ui={{ base: 'rounded-full shadow-lg' }}>Pill button</Button>

Change every button in the product — say it once:

import { defineConfig } from 'sv5ui'

defineConfig({ button: { defaultVariants: { variant: 'outline' } } })

Re-skin the whole application — change the tokens:

:root {
    --color-primary: oklch(0.55 0.25 270);
    --radius-lg: 0.75rem;
}

Colours are OKLCH, which keeps lightness perceptually even as hue changes — the reason a generated dark mode reads as deliberate rather than muddy. Light and dark switch themselves.

A small request stays a small change. Rounding one corner should never send you into the design tokens.

Forms That Speak the Language You Already Chose

The form layer implements Standard Schema, so it validates with whatever you already use:

<script>
    import { Form, FormField, Input, Button } from 'sv5ui'
    import { z } from 'zod'

    const schema = z.object({
        email: z.string().email(),
        password: z.string().min(8)
    })
</script>

<Form {schema} onsubmit={({ data }) => console.log(data)}>
    <FormField name="email" label="Email"><Input /></FormField>
    <FormField name="password" label="Password"><Input type="password" /></FormField>
    <Button type="submit">Sign in</Button>
</Form>

Swap Zod for Valibot, Yup or Joi and nothing else changes. A small thing until the day you join a team that made the opposite choice.

The Work You Do Not See

Most of what separates a component library from a folder of styled divs is invisible in a screenshot. A modal that returns focus to the button that opened it. A dropdown that closes on Escape without scrolling the page behind it. A field that announces its error to a screen reader once rather than on every keystroke. Keyboard paths through controls most people will drive with a mouse — until the one person who cannot arrives and finds the product unusable.

That work is slow, unglamorous and easy to get subtly wrong, which is exactly why it belongs in a library rather than being re-derived in every application. It comes with tests in CI, strict types, and a pure ESM package that tree-shakes so you ship only what you import. A set of reactive hooks covers the parts with nothing to render — clipboard, media queries, debouncing, focus trapping, scroll locking — so a copy button is three lines instead of a state flag, a timeout and a cleanup you would forget on unmount.

When a Table Stops Being a Table

This is where a general-purpose library usually ends and a second design system begins.

Hundreds of thousands of rows with filtering, inline editing and export is not a styled <table>. Real scheduling — month and week views, drag to reschedule, recurring events, saves that survive a flaky network — is not a calendar component. The usual path is to bolt on something standalone and then live with two sets of styles, two dark modes and two accessibility stories in one application.

SV5UI keeps going instead. @sv5ui/datagrid is a grid virtualised past a million rows, assembled from feature modules you opt into. @sv5ui/scheduler handles month, week, day, year and agenda views with drag and drop and an optimistic save pipeline that rolls back cleanly when a save fails.

Both are built on sv5ui. They read your config, your tokens and your dark mode, and the controls inside them are the same components your forms are made of. One design system, from the smallest badge to the largest grid.

Where It Will Not Fit

Svelte 5 and Tailwind CSS 4 are hard requirements, not preferences. And this is a young, independently maintained library: early adopters are using it in real applications and issues get answered quickly, but if what you need today is an enterprise support contract, weigh that honestly.

Try It

npm install sv5ui

The fastest way to judge any component library is to use it for an hour, and the live demo is built for that. Source at github.com/ndlabdev/sv5ui, package at npmjs.com/package/sv5ui.

Free and MIT-licensed. If it saves you a week, the things that help most cost nothing: star the repository, open an issue, or send a pull request. There is also a Ko-fi page if you would rather buy the maintainer a coffee.