I build a Web Component UI Kit.

Source: Dev.to

Background

I didn’t wake up one day and decide to build a UI kit. Like most things I’ve built, it started as a solution to a problem I had, for a project nobody asked for. I spin up a lot of side projects in my free time—little things that keep me entertained, challenged, and sharp on technology I’d otherwise only read about.

About a year ago I was deep in a sci‑fi browser‑game rabbit hole. I had spun up a few different projects across several frameworks just to get a feel for the latest versions of each, and I needed a UI that matched the aesthetic of the game without being tied to any one framework and without costing anything. This was a screw‑around project after all.

Kepler UI

That experiment became Kepler UI, a heavily sci‑fi‑inspired, zero‑dependency web‑component toolkit with roughly 20 components, a theme switcher, and even a web‑component‑based SPA router. It was over‑engineered for a game I never finished, but I liked how it worked.

The technology itself wasn’t the problem—working with a web‑component kit in my own projects was honestly easier than dealing with framework‑specific alternatives. The issue was that Kepler’s niche sci‑fi skin made it hard to use in most real projects.

Transition to Yumekit

So I stripped Kepler down, started fresh with a proper design system, and built something more practical: Yumekit.

• Website: yumekit.com
• About 30 components
• Zero dependencies
• Single JavaScript file import for full styling and functionality

You can drop Yumekit into a React, Vue, Svelte project, or use it with no framework at all—it doesn’t care. That was the whole point.

Features

Theming

Theming works through a dedicated component that lets you switch and customize themes dynamically without touching a stylesheet. It feels essential after wrestling with CSS specificity in other component libraries.

AI Integration

For anyone leaning on AI tools to build things right now, Yumekit ships with built‑in agent skills and LLM instruction sets. Tools like Cursor or Claude already have the context they need to use it correctly from the start. If you’re “vibe‑coding” a project together with an AI and want a UI layer that just works without a lot of hand‑holding in your prompts, Yumekit fits naturally into that workflow.

Community & Contribution

Yumekit is early, open source, and still evolving. If you try it and something is broken, confusing, or obviously missing, I’d rather hear about it now than six months from now when bad patterns have calcified. Issues and pull requests are open, and discussion is encouraged.

Feedback

What would make something like this actually useful to you?