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>
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:
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.
SOCIAL SHARE CARD GENERATOR