Accordion, Dialog, Checkbox, Calendar, Select, Tabs, Popover - 11 headless components built from scratch because existing Blazor component libraries didn't fit their design system.
This is a smart approach to a real problem. But it also highlights a gap in how Blazor's component ecosystem works.
The Design System Disconnect
Most Blazor component libraries are opinionated about styling. MudBlazor has its Material Design look. Radzen has its own design language. LumexUI, Syncfusion, DevExpress - each ships with integrated styling.
When your organization has its own design system (and most enterprises do), these opinions create friction:
- You pick a component library for functionality
- Your design team provides brand-specific styling
- You spend weeks overriding the library's CSS
- Some overrides break component behavior
- Library updates break your overrides
Headless components solve this by separating behavior from presentation. SummitUI gives you an accessible Dialog with keyboard handling and ARIA attributes - you add the CSS.
It's the same philosophy as Radix UI in React or bits-ui in Svelte. The SummitUI developer even acknowledged taking "a lot of inspiration from bits-ui and many other projects in the JavaScript ecosystem."
The Recurring Cost
But here's the thing: building headless components is significant engineering work. The SummitUI developer built 11 components with screen reader support for NVDA and VoiceOver. That's months of testing edge cases, keyboard navigation, focus trapping, and ARIA state management.
And it's work that's already been done in React (Radix), Svelte (bits-ui), Vue (Headless UI), and now Blazor (SummitUI). Each framework's community independently builds the same accessibility patterns from scratch.
For enterprise teams that need custom-styled components, this headless approach makes sense. For teams building internal tools - admin panels, data dashboards, back-office applications - there's a simpler path.
When Opinionated Is Better
Internal tools have different design constraints than customer-facing products:
- Brand compliance is less strict (your colleagues don't need pixel-perfect branding)
- Functionality matters more than visual differentiation
- Consistency across tools is more valuable than custom aesthetics
- Speed of development outweighs design flexibility
For these use cases, opinionated components that just work are preferable to headless components that require styling.
Ivy takes the opinionated path. Components ship styled, accessible, and ready for production:
var db = UseService<AppDbContext>();
var showDialog = UseState(false);
return Layout.Vertical()
| new Button("New Record", onClick: _ => showDialog.Set(true))
| db.Records.ToDataTable(r => r.Id)
.Header(r => r.Name, "Name")
.Header(r => r.Status, "Status")
.Config(c => {
c.AllowSorting = true;
c.AllowFiltering = true;
});
No CSS to write. No ARIA attributes to manage. No focus trapping to implement. The DataTable handles rendering, sorting, filtering, and accessibility.
UseState manages dialog visibility, form state, and component interactions - all with a single, consistent pattern.
The Decision Matrix
| Need | Best Approach |
|---|---|
| Customer-facing product with brand design system | Headless components (SummitUI, Radix) |
| Internal tool that needs to work well | Opinionated components (Ivy) |
| Complex accessibility requirements | Headless + custom styling |
| Fast development, consistent look | Opinionated framework |
SummitUI is solving a real problem for teams with custom design requirements. But many Blazor developers reaching for headless components are actually building internal tools - applications where opinionated, pre-styled components would save them weeks of CSS work.
The Takeaway
The Blazor ecosystem keeps producing new component libraries because existing ones don't fit every use case. That's healthy diversity.
But if you're building internal tools, the question isn't "which component library fits our design system?" It's "do we even need a custom design system for this?" If the answer is no, reach for something opinionated and ship faster.
Explore Ivy if you want components that work out of the box without design system integration.
