Building FrameUI: an Angular component library with a technical default style

Julian — Fri, 12 Jun 2026 17:39:13 +0000

I recently published a beta version of FrameUI, an Angular component library.

The goal was straightforward: build reusable Angular UI primitives with a themeable styling system, clear APIs, and documentation that shows real usage.

After sharing the first version publicly, I got useful feedback. Some people liked the project, but there was also a fair point:

It looked like another shadcn-inspired UI library. And honestly, that was true.

The problem was not shadcn

shadcn has influenced a lot of UI work in the frontend space. The approach is practical, the components are clean, and many developers like having code they can own and adapt.

But because the style became so recognizable, many new libraries now end up looking very similar.

That is not always a problem. If someone wants that exact style in Angular, there are already good projects for it, like ZardUI and Spartan.

But for FrameUI, I wanted a clearer reason to exist.

Not only in the API, but also in the default visual direction.

Changing the default style

After the feedback, I redesigned the default theme.

FrameUI now uses a more technical, blueprint-like style:

sharper edges by default
fewer shadows
clear borders
restrained red accents
visible structure
small corner details on sharp surfaces

The goal is to provide a default style that feels better suited for application UIs: dashboards, internal tools, editors, admin screens, and developer-facing products.

The component model

FrameUI is split into two packages:

@frame-ui-ng/foundation - contains shared styles, tokens, and providers.
@frame-ui-ng/components - contains the UI primitives.

The components use Angular selectors directly. Some are element-based, others are attribute-based. For example:

<button frButton type="button">
  Save changes
</button>

A more composed example:

<section frCommand>
  <input frCommandInput placeholder="Type a command or search..." />

  <div frCommandList>
    <div frCommandGroup>
      <p frCommandGroupHeading>Suggested</p>

      <button frCommandItem value="file" label="Go to File">
        <span>Go to File</span>
        <span frCommandShortcut>⌘ P</span>
      </button>
    </div>
  </div>

  <div frCommandFooter>
    <span><kbd>↑↓</kbd> to navigate</span>
    <span><kbd>↵</kbd> to select</span>
    <span><kbd>esc</kbd> to close</span>
  </div>
</section>

The template stays explicit. You can see the structure instead of hiding everything behind a single configuration object.

Styling through tokens

The default theme has an opinion, but it should not lock users in.
FrameUI uses CSS variables for component styling. That makes it possible to change things like spacing, radius, color, density, and component-specific details without replacing the component logic.
For example, the default theme uses sharp corners. But users can still opt into radius where it makes sense.
The same applies to component details like command item height, button spacing, input borders, or overlay surfaces.

What changed after feedback

The feedback helped clarify what FrameUI should not be.
It should not try to be another Angular version of an existing visual style.
It should be an Angular component library with its own default direction.

Current state

FrameUI is still in beta. There are components that need more polish. Some APIs may still change. Accessibility needs continuous testing. More real examples are needed.

The current focus is:

improve component coverage
refine accessibility behavior
keep the token system consistent
improve the docs
test the components in real application layouts
collect feedback from Angular developers

Links

Docs: https://frame-ui.com
GitHub: https://github.com/gamekohl/frame-ui

npm install @frame-ui-ng/foundation @frame-ui-ng/components

If you try it, I would be interested in practical feedback:

Does the API feel natural in Angular?
Are the primitives flexible enough?
Is the default style useful or too specific?
What components are missing?
What would block you from using it in a real app?

That kind of feedback is the most helpful at this stage.

DEV Community: Julian