I built an Angular component library, then redesigned it to not be another shadcn clone

FrameUI

I shipped the first beta of my Angular component library, posted it on Reddit, and got useful but uncomfortable feedback: it looked like another shadcn-inspired UI kit. They were right.

The initial goal was simple: build a set of reusable Angular components that feel modern, are easy to compose, and can be styled through tokens instead of one-off CSS overrides.

After the first public feedback, I realized something important: the library worked, but the visual direction was too familiar.

Some people liked it. Some people also pointed out that it looked like another shadcn-inspired component library.

They were right.

The first version was useful, but not distinct. shadcn has had a big influence on frontend UI. For good reason. The component model is practical, the default look is clean, and the idea of owning your component code has shaped how many developers think about UI libraries.

But that also means many new libraries start to look very similar.

This is especially visible in the Angular ecosystem right now. There are already good projects that bring this style to Angular, like ZardUI and SpartanNG. If someone is looking specifically for that kind of UI, those libraries are probably a better fit.

FrameUI needed a clearer reason to exist. Not only in terms of API or package structure, but visually as well.

Chaning the default style

After the feedback, I decided to change the default design direction of FrameUI.

The new style is more technical and blueprint-like. It uses sharper edges, restrained shadows, clear borders, small red accents, and visible structural details. The goal is not to make the UI decorative. The goal is to make it feel more intentional for application interfaces.

The kind of interfaces I have in mind are dashboards, admin tools, editors, internal tools, and developer-facing products.

FrameUI is still a component library, not a full design system. But I wanted its default theme to have a point of view.

What changed

Buttons, inputs, overlays, menus, command palettes, accordions, tabs, and other components moved toward a sharper technical style. Border radius is no longer part of the default theme, although users can still opt into radius through component tokens or component APIs where available.

Shadows were reduced and mostly kept for overlays. Borders became more important. Corner handles were added to some sharp surfaces as a visual detail, but only when the radius is zero. If a user chooses rounded components, the handles disappear.

The docs were also changed to match the new direction. Instead of presenting the components in a neutral documentation layout, the site now uses blueprint-like sheets, grid references, and technical framing. That is partly visual, but it also helps communicate what the library is trying to be.

The component model

FrameUI is split into two npm packages:

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

The foundation package contains shared styles, tokens, and providers. The components package contains the actual UI primitives.

The components are Angular-first. They use Angular selectors such as element selectors and attribute selectors depending on the component. For example, a select component can be used as an element, while a button is applied through an attribute.

The styling is based on CSS variables. The default theme is opinionated, but it is not meant to be locked down. Users should be able to change radius, colors, spacing, and component-specific details without replacing the component implementation.

A simple example:

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

And a more composed example:

<section frCommand class="command-demo">
  <input frCommandInput placeholder="Type a command or search..." />
  <div frCommandList>
    <p frCommandEmpty>No results found.</p>
    <div frCommandGroup heading="Suggestions">
      <p frCommandGroupHeading>Suggestions</p>
      <button frCommandItem value="calendar" label="Calendar">Calendar</button>
      <button frCommandItem value="emoji" label="Search Emoji">Search Emoji</button>
      <button frCommandItem value="calculator" label="Calculator" keywords="math,numbers">
        Calculator
      </button>
    </div>
    <div frCommandSeparator></div>
    <div frCommandGroup heading="Settings">
      <p frCommandGroupHeading>Settings</p>
      <button frCommandItem value="profile" label="Profile">
        <span>Profile</span>
        <span frCommandShortcut>⌘P</span>
      </button>
      <button frCommandItem value="billing" label="Billing">
        <span>Billing</span>
        <span frCommandShortcut>⌘B</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>

What I learned from the feedback

The most useful feedback was not that the library had bugs or missing features. That would have been expected for a beta. The more important feedback was about identity.

A component library needs more than a list of components. It needs a reason why someone would choose it over another option. That reason can be technical, visual, philosophical, or practical. Ideally, it is more than one of those.

For FrameUI, the answer became clearer after the redesign:

FrameUI is an Angular component library for application interfaces with a technical default style. That does not mean every app using it has to look like the default theme. But the default theme should give the library a recognizable starting point.

Still early

FrameUI is still in beta. There are components that need more polish. Accessibility needs continuous testing. The examples can be improved. The docs will keep changing. I also expect some APIs to evolve as the library is used in more real projects.

The current focus is not to claim that FrameUI is finished. It is to make the direction clear enough that feedback becomes more useful.

Why I am sharing it

I am sharing FrameUI because I want feedback from Angular developers who build real interfaces. Not only feedback like “this looks good” or “this looks bad”, but practical feedback:

Does the API feel natural in Angular? Are the components flexible enough? Are the tokens understandable? Does the default style help or get in the way? What is missing for real application work?

That kind of feedback is much more valuable than trying to make the library look finished too early.

FrameUI is available on npm:

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

The documentation is available at: https://frame-ui.com

The project is also on GitHub: https://github.com/gamekohl/frame-ui

If you try it, I would be happy to hear what works, what does not, and where the library should go next.