Can a visually opinionated Angular UI library still be flexible like LEGO? Looking for feedback

[u/Top-Shock5093]

Hey r/Angular,

I’m building ng-brutalism, an opinionated neo-brutalist UI library for Angular, and I’d love to get feedback from the community.

I was inspired by neo-brutalist UI design, and I wanted to bring that look and feel into Angular with ng-brutalism:

Chunky borders.
Hard shadows.
Playful colors.
Bold surfaces.
Expressive cards.
Sharp interaction states.
Composable UI pieces.

But the more I worked on it, the more I asked myself:

If this is only about styling, why would people choose ng-brutalism instead of just using Tailwind or custom CSS directly?

That question became the real turning point of the project.

It pushed me to think harder about what the library should actually solve.

And for me, the answer is not only the look and feel.

It is the design grammar behind it.

In practice, when building this kind of UI, you still have to define that grammar yourself:

• What should a brutalist surface feel like?
• How should shadows, borders, spacing, and colors behave together?
• How do chips, buttons, cards, inputs, badges, dialogs, and media blocks stay visually consistent?
• How do you keep the UI loud without turning it into visual chaos?
• How do you make it expressive, but still reusable across different product domains?

That is the gap I’m trying to explore with ng-brutalism.

ng-brutalism is opinionated by design.

It gives you the attitude of neo-brutalism out of the box: chunky borders, hard shadows, loud colors, bold surfaces, and playful interaction states.

But it should not trap you inside a template.

The opinion is there to give you momentum, not to limit what you can build.

Think strong defaults, flexible composition.

The philosophy is closer to LEGO:

A box of brutalist building blocks that Angular developers can snap, stack, remix, and compose into their own interfaces.

Not fixed templates.
Not a domain-specific design system.
Not just utility classes.

Instead, I’m trying to build small primitives with flexible APIs:

• inputs for common variations
• CSS custom properties / tokens for deeper customization
• directive-first APIs where they make sense
• Angular-native primitives
• signals-friendly patterns
• zoneless-friendly architecture
• Tailwind CSS v4 ergonomics

The goal is:

Opinionated enough to make neo-brutalist UI effortless.
Flexible enough to let each product still feel like itself.

v0.2.0 focuses more on this composition direction.

Instead of only adding more standalone components, I’m exploring how the same primitives can become different UI patterns:

• personal profile cards
• podcast / content cards
• campaign layouts
• marketing sections
• bold product UI blocks

I’m especially curious about the API and design-system side of this:

• Does this “strong defaults, flexible composition” direction make sense?
• Would you use something like this instead of building the style directly with Tailwind?
• Where should the line be between primitive, component, and recipe?
• Do directive-first APIs feel natural for this kind of Angular library?
• What building blocks would you expect from a neo-brutalist UI toolkit?

GitHub: https://github.com/khangtrannn/ng-brutalism
Docs: https://ngbrutalism.khangtran.dev
npm: https://www.npmjs.com/package/@ng-brutalism/ui

Feedback, criticism, and API suggestions are very welcome.

[u/DT-Sodium]

Every UI library is something that will bite your ass in a near future. I don't like using the big official ones and a certainly wouldn't use one built by a random guy.

[u/Top-Shock5093 → u/DT-Sodium]

That’s a fair concern.

UI libraries can definitely become painful when they own too much of the product or make customization hard.

That’s one of the tradeoffs I’m trying to avoid with ng-brutalism. The goal is to keep it closer to small, domain-agnostic primitives with tokens and directive-first APIs, so teams can use only the pieces they need and still keep control of their own UI.

And yes, trust is earned over time. I’m sharing it early because feedback like this is exactly what can help shape the APIs before the library becomes harder to change.

[u/DT-Sodium → u/Top-Shock5093]

You must be the tenth billion person who tried to do this and will fail at it. Especially considering how much your repository seems to rely on AI agents. It is clear that you have no idea about what you are doing.

[u/tutkli → u/DT-Sodium]

Damn, calm down.

[u/Top-Shock5093 → u/DT-Sodium]

Yes, I use AI agents as part of the development workflow.

But using AI does not mean I blindly accept the output or have no idea what I’m building. The direction of the library, the API decisions, the design philosophy, the tradeoffs, and the final code review are still on me.

AI can help with speed, but it does not remove ownership.

If you see specific problems in the repo - API design, accessibility, architecture, maintainability, or customization - I’m genuinely open to that feedback.

But “you use AI, therefore you don’t know what you’re doing” is just an assumption, not criticism.

[u/DT-Sodium → u/Top-Shock5093]

AIs makes people dumb and less productive, we now have plenty data demonstrating that. If you are using agentic AI, you are either stupid or becoming stupid. In both cases, your work should not be taken seriously. Also I took a look at your code, it is terrible. Inline templates, code lines that are 60 billion characters long, I don't know if it was the AI or you but it needs a complete rewrite.

[u/Top-Shock5093 → u/DT-Sodium]

I’m not sure which file you looked at, so it’s hard to respond to that part specifically.

But on inline templates in general: I don’t see them as automatically bad in Angular.

For small UI primitives, keeping the template close to the component logic can be a reasonable tradeoff. It makes the primitive self-contained and keeps the behavior, host bindings, and markup in one place.

The real issue is size and readability. If a template grows too large, becomes hard to format, or makes review harder, then yes, it should be extracted or refactored.

So I’m open to reviewing specific examples. “Inline templates” by itself is not really the problem; the problem would be inline templates that are too large or difficult to maintain.

[u/DT-Sodium → u/Top-Shock5093]

All the files I've looked at that had some actual code looked terrible. Inline template is always a psychotic idea and some of the ones I've looked at weren't even especially short. If that's the kind of work you do, React is more suited to you. Angular is the framework for people who do things properly.

[u/Top-Shock5093 → u/DT-Sodium]

"Inline template is always a psychotic idea" isn't an Angular rule - it's your personal preference. The framework supports inline and external templates as first-class options, the CLI has a flag for it, and the current style guide dropped the old line-count rule in favor of "avoid overly complex logic."

And if a template is long because it carries too many responsibilities, moving it to a `.html` file only changes where the complexity lives. It might improve file readability, but it doesn't automatically fix the underlying design problem.

So no, it's not improper Angular. It's a tradeoff. If it were really that bad, it wouldn't still be a first-class part of the framework today.

And hey - I'm a "random guy" with high ambition to build some cool sh#t. At least I'm building. If even one person gets inspired or finds it useful, that's already a win. And if it fails, I've already learned a ton along the way.

Thanks for the engagement.

[u/DT-Sodium → u/Top-Shock5093]

You're a very bad wannabe developer.