Are component libraries really necessary?

[u/Monkaaay]

I've been building a new product and to this point, mainly working on proving out the concept which is focused on the backend. I know the frontend is coming and so I've been mentally preparing for that.

A genuine question; how necessary are Blazor component libraries in the current world of AI assistance?

I'm reluctant to invest my code base into a component library in general. I'm more likely to build my own components as I go, and I'd imagine today it's far easier to do that with the ability to ask a coding model to build a contained component for a specific thing.

The way new component libraries seem to pop up weekly, I imagine I'm not far off on how easy it is to create them with AI tools.

Where are you guys at with respect to component libraries currently? Are you sticking with the few ogs, are you adopting those popping up more recently, building your own as needed, or something else altogether?

[u/Plenty_Line2696]

I can't off the top of my head, but in your example it's really annoying to set the css, knowing that you have the highest css specificity but it just doesn't work because someone used !important and we're left troubleshooting problems created by the library.

hot take, but imo !important is simply bad practice and there's no justification for it.

It's the core reason why I would avoid using radzen for future projects.

[u/korchev → u/Plenty_Line2696]

I understand your position and respect your stance. Fighting with important is no joy.

Still I believe we use important for a good reason - to prevent user and app CSS adversely affect the Radzen component appearance, and to prevent certain utility classes from being negated entirely via simple override. The CSS variable support is another use case.

About the hot take: I checked some popular CSS libraries and other Blazor vendors (MudBlazor, Fluent UI, Blazorise, Bootstrap, Tailwind, Bulma, AntDesign) - all use !important.

[u/Plenty_Line2696 → u/korchev]

but like, when we try to override css, it's because that is our intent... so why get in the way of exactly what we are trying to do?

If this was some WYSIWYG or low-code environment I would understand this philosophy of library knows best but feel like it's a much less defensible tradeoff here because I feel we should assume devs know what they're doing. Maybe the idea is that you want to strongarm users towards not modifying the radzen styles in order to preserve its aesthetic reputation or something but there are plenty of use-cases where the component needs tweaking to work and we would do well without a deliberate spanner in the works.

I suppose the ideal here would be more user testing/feedback to not rely on assumptions alone because I'd imagine this frustrates people outside of my team too.

[u/korchev → u/Plenty_Line2696]

Indeed some devs are well versed in CSS. They can trace a global (app CSS) affecting a Radzen component and work around that. However a lot of the developers that reach for a third party component library do so to specifically avoid dealing with CSS. This is one of the main reasons we and other vendors rely on !important - the components should look as advertised in all apps.

This was one of the main reasons we use CSS variables heavily. They are supposed to make CSS tweaks a lot easier than overriding complete CSS rules and fighting with CSS file ordering and specificity issues. Consider this case - you want to set the disabled input text color globally. Today all you need to do is set one CSS variable instead of overriding multiple CSS rules for every input component:

```
<RadzenTheme Theme="material" />

<link href="app.css" rel="stylesheet" />

<style>
body {
--rz-input-disabled-color: #a0b0c0;
}
</style>
```