Why I built the 78 UI Kit
Every developer has a drawer. Mine was a folder of "nearly the same" code: a card here, a modal there, a helpers.js I'd been carrying from project to project for years, each copy slightly different from the last because I'd fixed a bug in one and forgotten the others.
This summer I finally opened the drawer properly.
The helpers.js audit
Before building anything new, I went through one copy of that old helpers.js and checked which functions were actually still called. Three out of fifteen. The other twelve had zero callers. They'd been copied faithfully into project after project and never used again.
That turned out to be the most useful lesson of the whole thing. The code that survives is the code a real screen needed. The "this might come in handy" code just rides along, gets out of date and quietly confuses you a year later. So the rule for the kit became simple: nothing goes in until a real app needs it.
What I wanted
- No framework and no build step. One stylesheet, one script, drop them in a page. If I can't open a file in a text editor and understand it, it doesn't belong.
- Light and dark, properly. Not a dark mode bolted on at the end. Every component, every state, both themes.
- Theme-forward. Most component libraries make color the hard thing to change. You change the accent, then rebuild, then find the three places it was baked in. The kit uses CSS custom properties (tokens) for every color, so a theme is just a short block of variables. There's a theme generator that writes the block for you.
- The tables and charts match too. This was the itch that started it. Your buttons look lovely, then you drop in a data table or a chart and it's from a different planet. The kit ships small adapters for Tabulator, FullCalendar and Chart.js, so they pick up the same theme, including when you switch it live.
Built for dashboards
Almost everything I build ends up with at least one dashboard: a trading app's account page, a site's health check, a "how are we doing this week" screen. So the kit was built to be dashboard-friendly from the start, not just able to sit next to a chart.
That means stat and KPI cards, and a set of small charts that need no chart library at all: sparklines, progress bars, bar rows, donuts and gauges, trend indicators, figure rows and split bars. You write a little HTML with your numbers in it, and the kit draws the rest. They use the same color tokens as everything else, so they switch between light and dark instantly, with nothing to redraw.
It fills a gap I kept falling into. Often all a card needs is one small chart, and pulling in a whole charting library (and then theming it) for a 7-day trend line is a lot of weight for a little picture. When you do need a full chart, with axes, tooltips and multiple series, the Chart.js adapter makes it match the rest of the page.
The rules it lives by
A few rules that sound fussy but have saved me more than once:
- Tokens only. No hard-coded colors anywhere. If a color isn't a token, it's a bug.
- The demo page is the spec. If a component isn't on the demo page in both themes, it isn't real.
- Docs are part of "done". A change isn't finished until 78uikit.com shows it with a live example and copy-paste code.
- AI assistants get docs too. The kit ships an
llms.txtand anllms-full.txt, plain-text references a coding assistant can read so it uses the real classes instead of guessing. I use AI to build, so it would be silly not to. - No breaking changes without a very good reason, and a loud note in the changelog when anything looks different.
Built by using it
The first real customer was 78trade, a trading app I'm building. Every time it needed something the kit didn't have, the rule kicked in: if two screens hand-build the same thing, it gets promoted into the kit, documented, and then the app deletes its local copy. A good chunk of the next release is exactly that: little pieces 78trade built by hand two or three times.
Since then it's spread. 78uikit.com is built with the kit, obviously, and so is this blog.
How it gets built
Same as everything else here: I work with Claude in two roles. Hank (the planning and review side) turns my "it'd be nice if…" into proper tickets with a clear "done when", and Bob writes the code against them. I decide what goes in and what "done" means, and I look at every change in both themes. The rules above exist partly because of that setup: when a lot of the typing isn't yours, "the demo page is the spec" and "docs are part of done" are how you keep it honest.
Try it
It's free and MIT licensed. The whole install is a few lines in your <head>, and it's all on 78uikit.com, along with the component gallery and the theme generator. The code is on GitHub.
Next up, I'll walk through how it got from a first commit to v0.3.0 in about six weeks, and the release I'm finishing now.