Why we built Peacock

We build Redvars, a platform for business applications: records, forms, lists, approvals and the rules that tie them together. To build it, we needed a UI library. We couldn’t find one that did everything we needed, so we built Peacock.

1. It had to work in any framework

Our apps don’t all use the same stack, and we didn’t want to rewrite our UI every time a framework changed. So Peacock is built on web components (Lit). The same tags work in plain HTML, React, Vue and Angular. For the frameworks, we generate typed packages with two-way binding: v-model in Vue, ngModel and formControl in Angular, value and onInput in React. You can load it with one script tag, or install it from npm.

2. Business apps need more than buttons

Most free libraries stop at buttons, inputs and modals. Real products also need data tables, date pickers, rich-text and code editors, charts, kanban boards and dashboards. Ours also needed to show how a process works, so Peacock includes:

a workflow builder for business rules, with branches, loops, waits and error paths, plus a debug view that shows a real run step by step
org charts and other tree charts
dependency maps for services and assets
ERDs that draw a schema and let you edit it

These are usually paid add-ons, or they don’t exist at all. In Peacock they’re 140+ components, all built on one design system.

3. AI that keeps people in control

Every product is adding an assistant. Most of them either do too little or act without asking. We wanted AI that works inside the app the way a good colleague would, so Peacock’s AI components follow three rules:

Everything the assistant wrote is marked, and shows why.
It never writes on its own: values are suggestions, and records are drafts the person confirms.
Turning AI off removes every trace of it, and the page keeps working.

Peacock never calls a model. Your app registers one provider, and the components show the state you pass in: summaries that cite their sources, a chat panel, suggested field values, and answers shown as charts and tables.

4. The boring parts, done properly

These are the things nobody notices until they’re missing:

Fields take part in native forms: validation, submit and reset work as expected.
Overlays open in the browser’s top layer, so z-index fights are gone. Escape closes only the topmost one, and focus goes back where it came from.
Every component mirrors correctly in right-to-left pages.
All built-in text can be translated in one call, and dates and numbers follow the page’s language.
It can run with no CDN, for intranets and strict content security policies.
It’s accessible by default: semantic HTML, ARIA, keyboard support and focus management.

5. It should look like your brand

The theme builder makes a complete theme from one colour, using Material 3 colour science so every colour pair keeps readable contrast. Pick your colours, corner shape and fonts, check them on a sample app, then copy the CSS. Light and dark mode come with it.

Why open source

We use Peacock every day to build Redvars, so it’s tested on real products, not only demo pages. Anyone building serious product UI runs into the same problems we did. Making it open source means other teams can skip the years of work we put in, and their feedback makes it better for everyone.

What we’d love from you

Try it on https://peacock.redvars.com. Every component has live examples, there are ready-made blocks (dashboards, settings, login, kanban and more), and a guide for each framework. Tell us what’s missing, what’s confusing, or what you’d build with it. And if it helps you, a star on GitHub means a lot to a small team: https://github.com/redvars/peacock

Thanks for checking it out! 🦚