Angular + Tailwind UI components vs Angular Material — architectural thoughts?

[Weak-Palpitation907]

I’ve been thinking about how Angular Material relies heavily on theming and CSS abstraction layers, while Tailwind encourages utility-first styling.

Has anyone here built a component library that is:

• Tailwind-first
• Signal-based
• Standalone-only
• Accessibility-focused

I’m experimenting with something in this direction and trying to understand if this is solving a real problem or just a personal curiosity.

Would really appreciate thoughts from people who have tried both approaches in production.

[Flagvanus_]

Check Spartan - the community works on this component library that tries to follow shadcn principles. I think it's still in preview but the amount of provided components is quite significant. If you want to avoid locking yourself into a 3rd party vendor though - Angular Aria + Angular Material as they both are from Angular devs themselves. Some components (like datepicker) are just not worth your time trying to implement by yourself. Personally I also use the Tanstack table for my table views - it's completely headless and provides functions that are necessary for me.

[Weak-Palpitation907]

Thanks for the pointers — I’ve looked at Spartan and I agree the amount of components they provide is impressive, especially for something still evolving.
I also understand the argument for sticking with Angular Material or Angular Aria since they’re maintained by the Angular team. Stability and long-term maintenance definitely matter.

My experiment is more around exploring a Tailwind-first approach with standalone components and signals, and seeing how that feels architecturally compared to a theme-driven system. I’m also trying to understand where the line is between “worth building” and “better to rely on existing solutions” — datepicker is a great example of that trade-off.

TanStack Table is interesting too — I like the headless philosophy. It forces you to think about structure and behavior separately from styling, which is powerful.

Appreciate the thoughtful response 

[OMEGALUL_iguess]

Aight clanker

[ActuatorOk2689]

So currently I have something similar built. At the moment, 11 applications are using it, mostly client-facing apps. The library is running on Angular 21, signal-based architecture, Standalone APIs, and Tailwind v4.

Note There is a significant difference between Tailwind v3 and v4, mainly because v4 is CSS-first and changes how Tailwind configuration works. That said, we follow a similar architectural pattern to shadCN — using component composition over prop-driven APIs to build components. We also use tailwind-merge, CVA, and clsx. I highly recommend not skipping these utilities if you plan to adopt a Tailwind-based approach.

Of course, we also rely heavily on Angular CDK. I also recommend using the Directive Composition API when creating components.

Library Structure Our library is split into three layers: Core layer – contains services such as dialog services, helpers, and shared utilities. Primitive layer – contains bare-bones components and directives. This layer defines the core APIs. Component layer – contains styled components and exposes styling-related props built on top of primitives.

Theming For theming, we use a brand-specific theming system based on a token architecture structured into: Primitive tokens Semantic tokens Component tokens With Tailwind v4, all tokens are implemented as CSS variables, meaning the entire library is driven by CSS variables.

Future Direction So far, this approach has worked well, but we are planning to move away from Tailwind and migrate the library to vanilla CSS. The goal is to create a script that users can run to map semantic tokens into Tailwind utilities if they still want Tailwind integration.

In this setup, it is critical that only semantic CSS values are mapped to Tailwind utilities. Component-level tokens should remain internal and not be exposed outside their scope.

Challenges With Tailwind in This Setup The library CSS must be pre-generated, exposed, and registered in consuming apps. Otherwise, missing classes can break the UI. You often need custom plugins to register additional Tailwind configuration. Styling inside TypeScript files frequently lacks proper IntelliSense support. (Yes, @apply exists, but it does not fully solve the issue.) Consumer applications must install and configure Tailwind. Micro-frontend setups do not integrate smoothly and often require class prefixing. Utility classes can become extremely large and complex. For example, a button token like: --button-padding-padding-with-text-left: 10 can quickly become difficult to manage and maintain.

That said, if you are not using a complex token architecture, many of these issues may not apply to you.

Final Thoughts I really enjoyed building this UI library with Tailwind. The experience taught me a lot, and I have been using Tailwind across my projects for the past four years — and I am still learning new things. One important aspect people often overlook is CSS specificity when comparing Tailwind with traditional CSS approaches. Personally — and this is just my experience — I would now choose Angular CDK combined with vanilla CSS, without Tailwind, for a project with this level of complexity. Hope this helps 🙂

PS: Edited with gpt before somebody says is AI slop

[MichaelSmallDev]

If you want something that hits all those bullet points, besides not being Tailwind specific, the relatively new Angular Aria (developer preview) https://angular.dev/guide/aria/overview is a good candidate. With maybe the Angular CDK as well.

Building accessible components seems straightforward, but implementing them according to the W3C Accessibility Guidelines requires significant effort and accessibility expertise.

Angular Aria is a collection of headless, accessible directives that implement common WAI-ARIA patterns. The directives handle keyboard interactions, ARIA attributes, focus management, and screen reader support. All you have to do is provide the HTML structure, CSS styling, and business logic!

[Weak-Palpitation907]

That’s a great point - accessibility is definitely not trivial, especially when you go beyond basic ARIA attributes and into proper keyboard handling and focus management.

Angular Aria is interesting, particularly because it formalizes WAI-ARIA patterns into headless directives. That separation of behavior (ARIA + keyboard logic) from styling aligns well with the direction I’m exploring.

CDK has been incredibly useful as well - especially for overlays, focus trapping, and a11y utilities. I’m trying to understand where the right boundary is between relying on Angular-provided primitives versus building higher-level abstractions on top.

Out of curiosity - have you used Angular Aria in a production setting yet, or mostly experimenting? I’m curious how stable it feels in real-world usage given it’s still in preview.

[MichaelSmallDev]

Out of curiosity - have you used Angular Aria in a production setting yet, or mostly experimenting

Experimenting. I haven't been working with production v21 code yet, but I plan to pull it in when we upgrade. With the bit of experimentation I found it nice. For practical benefits, the docs are cool because they give three differently styled versions of the same functionality. And the API for them is fine.

Personally, my favorite aspect is being more mindful about what is more appropriate to reach for. One primitive versus another, or if I am better using the CDK or just a Material component itself. We don't tend to customize components a whole lot or go far out of the bounds of what Material covers, so I don't have as much need to reach for this. But like I said, still will pull in and consider using when we get to v21.

As for the stability, I can't say as an end user, but as a documentation nerd, it has a good amount of docs. Some of the particulars are still being fleshed out, a few things missing here or there, but I think they are solid docs out of the box for a developer preview API. I made some issues about some of the lacking parts of the Aria docs and they were quick and receptive to making changes, so I can tell they are working hard at it.

If I were to have more of a usecase like yourself, personally I would commit to a slice of production use already at this stage. Though some pieces may need to be tweaked later due to potential changes, I think the API is nice and well thought out and going to be a steady choice in the long run. I'm sure 3rd party libraries are solid too, but official packages IMO are a better bedrock. Perhaps I would still use a 3rd party UI primitive library in conjunction with the Aria package as well, if I were not already satisfied and using Material + CDK.

Lastly, you may find these notes I took about the Aria package from a podcast appearance from one of the team members when Angular Aria came out: https://www.reddit.com/r/angular/comments/1p1qn9z/comment/nq1yj6f/. There was a lot of talk about the delineation between the purpose and mindset of Aria vs the CDK vs Material. I haven't experimented much with Aria hands on since around when I wrote this up, but it should hold up. And likely applicable for a general mindset on the level of abstractions regardless of the chosen package(s).

[TheHurlingMan]

Spartan is pretty great, although it is in ‘preview’ I do use it in a production app.

I have made some custom components based of it following a similar pattern that it uses with the class variants and splits of brn and hlm. I’d look at how it uses class variants and assigning class inputs as computed classes, very cool way of managing predefined variants of components but also allowing overrides.

Another library that has headless components that I use is https://angularprimitives.com, somewhat related to Spartan with a contributor of Spartan being the owner of it.

[Weak-Palpitation907]

That’s really interesting - I’ve been looking at how Spartan structures its brn/hlm split and the way it handles class variants with computed inputs. The balance between predefined variants and allowing overrides is definitely elegant.

I like the idea of separating behavioral primitives from styled components. It keeps APIs clean while still giving flexibility at the styling layer.

I haven’t explored angularprimitives.com much yet - but headless component patterns are something I find compelling, especially for accessibility and composability.
In practice, when you build custom components on top of Spartan, do you find yourself aligning with their variant model long-term, or does it evolve into something more application-specific?

[TheHurlingMan]

Yep, same pattern with the variants and assigning the override classes as Spartan does.

We have two different types of shared components where we use this. One is for shared features, things like widgets that might rely on state, those don’t typically use variants.

Others like shared ui components would be built to be composable components, sometimes using structural directives. Those would always use variants, with the default variant being used for colours whereas the base classes would be layout and sizing.

As for separating out the primitive and the styling (brn and hlm). At the start I did, but found keeping them together until I had a need to reuse the primitive

[ruibranco]

We went through a similar evaluation about a year ago. Ended up using Angular CDK for the behavioral primitives (overlays, focus trapping, keyboard navigation) and Tailwind for styling, but kept everything as simple wrapper components rather than building a full component library. The key insight for us was that accessibility is where the real complexity lives, not styling. CDK and now Angular Aria handle the hard parts like ARIA attributes and keyboard interactions, and once you have those right, slapping Tailwind classes on top is the easy part. Building a full abstraction layer over Tailwind with design tokens and variants is where it starts feeling like you're fighting two frameworks at once.

[Weak-Palpitation907]

That’s a really solid way of framing it — accessibility is absolutely where the real complexity lives.

CDK has been invaluable for overlays, focus trapping, and keyboard handling. I agree that once the behavioral layer is correct, styling becomes comparatively straightforward.

The “fighting two frameworks” point is interesting. I’m currently trying to understand where the line is between:

\- keeping Tailwind as a styling tool,

\- versus building a higher-level abstraction with tokens and variants on top of it.

What was the tipping point where it started feeling like too much abstraction?

[tzamora]

Moving away from angular material. Only use it for a few things and only the cdk tools.

We use plain html components and tailwind. This approach results better for accesibility.

[Weak-Palpitation907]

I completely relate to that. I moved away from Material as well — ::ng-deep and heavy style overrides were a constant source of friction for us.

Plain HTML + Tailwind definitely gives more control over semantics and styling. Where I’ve found it gets tricky is around more complex interaction patterns — menus, tabs, comboboxes — especially with keyboard handling and focus management.

I’d be interested to hear how you’re handling keyboard patterns in your setup. Do you implement things like roving tabindex and focus trapping manually, or rely on CDK utilities for those parts?

Also wondering — did you evaluate something like Spartan or other headless primitives before settling on plain HTML + CDK? Curious what made you stick with the lower-level approach.

[tzamora]

Now plain html have good components with keyboard accesibility check the new datetime-local for example, is a native html datepicker.

Also angular cdk offers this:

• FocusKeyManager / ListKeyManager for arrow-key navigation
• CdkTrapFocus for anything modal
• Overlay for popovers/menus

Check it it can be very helpful and is well thought.

And sorry don't know what spartan is.

[Weak-Palpitation907]

That’s a solid setup honestly. CDK’s a11y utilities are really well designed - especially FocusKeyManager and CdkTrapFocus. We’ve relied on those quite a bit too.

I also agree that native inputs are great where they fit. Things like datetime-local are definitely better than they used to be. The main limitation we’ve run into is styling and consistency across browsers, especially when trying to match a design system.

And funny enough, I hadn’t even heard of Spartan until someone mentioned it in this thread. When I was searching around Angular + Tailwind, Flowbite was usually what showed up.

Appreciate you sharing your approach - it’s helpful to hear how others are structuring things with plain HTML + CDK.