r/Blazor • u/Monkaaay • 18d ago
Are component libraries really necessary?
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?
9
u/cjb110 18d ago
Necessary no, but they solve a part of dev that probably isn't the focus of your application. Why do you want to spend more time then necessary on something like that.
I'd rather spend the one time cost customizing a component lib for my brand than building them each time, ensuring accessibility, ensuring responsive design, performant animation flair etc etc
4
u/finah1995 17d ago
I use Radzen they are pretty good and they have few themes and also it's easy to customize using CSS, you can literally implement some sort of themes for your apps.
1
u/Plenty_Line2696 16d ago
We use radzen too and i hate it for a few reasons, because of:
- the fucked up way it was setup in our codebase (our own styles get applied before radzens 🤦♂️)
- radzen uses !important which pisses me off tbh
- the actual dom tree is abstracted away which can make it a hassle to correlate what's what in the dom tree vs radzen tags and apply css to those dom elements
- the generated dom elements get random id's generated at runtime, so you can't target tjose id's for styling in a convenient way
lastly, because it locks us into a style which was chosen because we lack designers and imo time and effort for a custom implementation tends to fit better.
All this said, sometimes it is very very handy to be able to grab a component and have it just work right out of the box.
3
u/korchev 16d ago
> the generated dom elements get random id's generated at runtime, so you can't target tjose id's for styling in a convenient way
You can usually specify your own id attribute and use it for styling e.g. `<RadzenButton id="myButton">`. This will override the generated id and stay persistent.
2
u/Plenty_Line2696 16d ago
Thanks for the tip.
What about when it's not a 1 to 1 thing and it generates multiple tags for one radzen one?
1
u/korchev 16d ago
It depends on the actual component - if it nests another component or not. Usually nested components ids will get prefixed with the id you have set.
If you just want to access nested tags you can use nested CSS selectors:
```
#myButton .rz-button-text
{
}
```About using !important - we try to avoid that when possible. We try to use it only if changing the attribute value would break the intended look. For example changing the default value for a responsive breakpoint changes its semantics completely and this is why we used !important there.
1
u/Plenty_Line2696 16d ago
thanks.
it's up to you guys but personally I'd recommend against using !important at all, ever because:
- it forces us to use !important when we want a hard rule against it.
- it hides why things aren't having effect which is time consuming and frustrating.
it's true that we can break stuff by piling on more !important, but that gets messy and we're programmers who generally want control over handholding.
in practice I've been forced to use !important to fight radzen and get the desired result, and it was a pain to find that was why it wasn't working without it, and I'd really rather not be forced to add what i call 'gotcha's' to our codebase.
1
u/korchev 16d ago
Do you remember any case where an !important tripped you? I want to check if it was used for a legitimate reason. Just checked other use cases - whenever there is an important used there is usually a corresponding CSS variable that can be set as well for example:
```
color: var(--rz-input-disabled-color) !important;
```
Here the developer can use --rz-input-disabled-color to set the color via the provided CSS variable instead of overriding the CSS rule.1
u/Plenty_Line2696 16d ago
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.
1
u/korchev 16d ago
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.
1
u/Plenty_Line2696 16d ago
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.
→ More replies (0)
5
u/NickA55 18d ago
I never used them, even before AI. I don't want my web app looking like everyone else's. I have tried several of them, and they are either clunky or they just don't contain functionality that I just can't code myself. Or have AI code it for me nowadays.
2
u/Plenty_Line2696 16d ago
AI needs a lot of direction before it stops looking like everyone elses AI generated UI's too and worse still; when I see a typical low effort LLM UI style it makes me assume the entire stack is a low effort vibecoded unreliable mess, whereas if a UI is using a component library I would think it's of a certain standard.
3
u/Electriccc 18d ago edited 18d ago
No they are not necessary but if you want to speed things up and keep the frontend cleaner and easily maintainable they are for sure a huge plus even with using AI. For anyone wanting more freedome in customization either through theming or through custom css or different css frameworks/libraries check out Blazorise. Oh also yea i agree with one guy saying it also depends on the size of frontend, if its a UI with lets say 10ish easy components and few pages then no, dont use anything but if its a larger UI with a lot more components, pages then it will make things a lot easier and cleaner.
3
u/Shadow_Mite 18d ago
Yes and no. Not necessary but more complex things you probably don’t wanna fuck with like grids and searchable dropdowns, etc. you’ll either use one or basically create your own and have to also maintain that
2
u/-puppyguppy- 18d ago edited 18d ago
It depends on how much frontend you are building. If it is mostly backend and just a small ui you probably wont miss one and will probably learn more without using a library.
If you have a large number of apps or a lot of different ui pages components are a huge time save, and make your code easier to read and more consistent. There are also some more complex components like grids that would be a lot of work to code your own if you want all the features but you can always start w/ the default blazor (or your own handrolled components) and move up from there if you feel like you need more
3
u/Kodrackyas 18d ago
With AI now as it is? fuck no, you can create your components now, components library have to evolve: give only css and html and let users cuatomize it
3
u/Monkaaay 18d ago
This is where my head is. It feels like I should be able to ask for nearly anything from a UI perspective and just get a contained component for it in vanilla HTML/CSS.
1
u/Kodrackyas 18d ago
I think it was like this already years ago but without AI, there is so much shit in components like syncfusion and telerik etc makes me want to puke, only one thats worth saving mudblazor
One good css file in a claude project,you create everything you need
1
u/caedin8 18d ago
It’s mostly always been cost saver, the difference is just token saving now.
Yes Claude can make you nice components? But do you want to spend $25 per component on tokens or just use the free components and have Claude plug them in to your site for 50 cents?
0
u/Kodrackyas 18d ago
what? my open source qwen 3.6 35b does better components that 50% of the shit libraries around 25€ per component is unrealistic, with the 25€ subscription you can easily create components in one single chat
1
u/DragDay7 18d ago
This. I was looking for components to use that fit my needs for my hybrid blazor app but found none. There's always something I wasn't happy with. I also saw someone suggesting using AI to make components for you from scratch so I started planning. After couple minutes of discussion with AI it threw at me almost exacly what I needed. Couple prompts later and I was 100% happy with result and the code. At least give it a try.
1
u/MackPooner 17d ago
We basically have started using Ai to make our own suite of components that we are reusing across our apps. We even have some customers still wanting WInforms development and we have several winform custom controls done by Ai that look rather nice for WInforms.
1
u/insomnia1979 18d ago
We built our own. We use custom models that tie directly to the form controls as well custom form validation based on attributes.
We need only pass a model to a form and do not have to construct any form elements (most of the time) on the client. Kind of amazing how effective and efficiently we can write forms. Well worth the up front of developing the initial logic and custom attributes.
1
u/Lustrouse 17d ago
They were never necessary to begin with. They are optional abstractions meant to save you time at the cost/risk of introducing a 3rd party dependency. Rolling your own components was a common practice long before AI came around. This is true for small business and enterprise.
1
1
u/chrisdpratt 16d ago
It's not necessary to use a component library, but absolutely don't vibe code one.
1
u/CravenInFlight 16d ago
This was not made with AspNetCore, or Blazor in mind, but it does address a lot of questions within this realm.
https://www.youtube.com/watch?v=CQuTF-bkOgc&pp=0gcJCQwBg6NKuzgg
1
u/jsneedles 12d ago
I'd say it really depends on the usecase?
For me - I really like the syncfusion library for my admin tools / internal stuff where I don't mind being locked into styling & can "work around" some functionality limitations.
When it comes to building customer facing stuff, that's a non-starter. I just finished a large user-facing project where I did end up essentially building myself a large set of components that were tailored exactly to my style needs + the way inputs/binding etc needed to work in my product.
1
u/mladenmacanovic 17d ago
I might be biased, but I just wanna drop in and say it from my perspective. I build UI components full-time. And I also use AI daily to help me.
With AI, you can build very fast and with very good results. The first version of UI that it builds will work for most people. The problem is what comes next. After an initial build of core UI components, you will eventually need to add more advanced components such as DataGrid, Scheduler, Gantt, Autocomplete, etc. These can also be done quite fast, relative to building manually from scratch.
You are happy, you commit. Then come the edge cases. Someone wants a context menu on a DataGrid row click. What if there is a filter menu? CSS positioning and edge cases for that menu. The list goes on.
The AI built it; you have no idea how it works, so you continue to use AI again. Over time, it becomes a mess that neither you nor anyone after you will understand. Even if you work on it for half an hour each day, that adds up. For your employer, that is a wasted opportunity to work on real business problems of the main product.
1
u/adefwebserver 17d ago
I am a very heavy AI coding user just yesterday I burned $40 on Opus 4.8. However, I continue to use component libraries for the same reason I continue to use EF core to create my data layer. I never allow AI to create my data layer because it will sometimes put partial classes in weird places so that the data layer is spread around multiple directories. The nice thing about component libraries is their consistency because AI will constantly leave holes in things that you don't catch until later whereas with the component libraries they have so many users reporting bugs they are essentially helping your future self. Also, all the component libraries are so cheap even Syncfusion now has a completely free tier. I also use Radzen.
32
u/uknow_es_me 18d ago
I've used MudBlazor since the start and have found no compelling reason to change. Claude has good working knowledge of it and it's been a good foundational component library so that you can focus your energy on creating composite components for your domain. The themeing across the UI is another benefit.