DEV Community

rhymes
rhymes

Posted on

How many UI libraries are too many?

from Curated list of framework component libraries for UI styles/toolkit

Top comments (15)

Collapse
 
david_j_eddy profile image
David J Eddy

No such thing as not enough choices. For every person there is a dozen different ways to do the same thing. Personally, I am ok with this. I'd rather spend time researching than re-working a hasally (or not best) chosen option.

The PHP eco-system is not much better. Here are the option for Stripe payment interface packages:

PHP Stripe packages

Collapse
 
rhymes profile image
rhymes

Don't you ever think that some libraries exist because instead of contributing to something or opening a discussion, the dev decides their way is going to be better than the existing?

I'm not talking about forks, just libraries started because somebody didn't like the existing approaches

Collapse
 
puritanic profile image
Darkø Tasevski

I'm not talking about forks, just libraries started because somebody didn't like the existing approaches

Every library out there. Vue rings a bell.

Thread Thread
 
rhymes profile image
rhymes

Ahhaah true.

In the end it worked out for Vue.

I guess in general the frustration we all feel is balancing the infinite choices with the requirements, preferences and that sense of dread that pops up when you think "is this the best possible choice?".

Dealing with complexity basically.

Collapse
 
krofdrakula profile image
Klemen Slavič

I don't see a problem with having competing implementations, as every instance is an oppprtunity to discover a good approach to express and compose UI components.

What I have a problem with is people choosing a library as if it were a framework by tightly coupling to it before verifying that it fits their requirements, both at present and at any point in the future.

Any library listed here should be replaceable if need be. If that's not the case for the project in question, any change in requirements will mean the project needs to basically start the UI from scratch.

Collapse
 
rhymes profile image
rhymes • Edited

Any library listed here should be replaceable if need be. If that's not the case for the project in question, any change in requirements will mean the project needs to basically start the UI from scratch.

Yes and no, depends on how much custom code you have.

You might have to rewrite your custom "button widget" that uses X to use Y, fix the JS code (because maybe the name of the event you're handling has changed), fix the customizations and so on.

It's doable, but it's never going to be free.

Collapse
 
ben profile image
Ben Halpern

This really does seem like a JavaScript/frontend kind of thing.

Not that it's a problem per se, but it's not exactly ideal.

It's hard to say definitively why it's not ideal, but it seems like there is a lot of wasted energy in frontend land trying to keep up with what's going on.

Collapse
 
rhymes profile image
rhymes • Edited

This really does seem like a JavaScript/frontend kind of thing.

Sure, after all CSS allows you an infinite array of aesthetical choices and JS an infinite array of behaviors.

Some UI libraries are basically frameworks and they require the developer to marry the philosophy. That's also probably why there are so many, different ways of solving the same problem.

It's hard to say definitively why it's not ideal, but it seems like there is a lot of wasted energy in frontend land trying to keep up with what's going on.

I also see a lot of wasted energy into solving the same problem over and over. If you think about it, most of all those libraries have: buttons, inputs, ways to display errors, probably a grid based responsive layout, modals, a table and so on.

I'm not saying there's anything wrong either, it's just that... I don't know... it's a feeling

Collapse
 
gypsydave5 profile image
David Wickes

CV driven development?

Collapse
 
gypsydave5 profile image
David Wickes

Wow. I mean, wow. A 'curated' list of framework component libraries? What about all the libraries that didn't meet the curator's high standards?

'Framework component libraries'? So not only do I get to pick my ghetto when I choose a frontend framework, but now I can add another ghetto inside my ghetto when I choose a component library? How on earth is this a good idea?

Sure, you can probably switch one out for another, but it's not going to be zero cost. Nobody ever thinks of the downsides.

Read a nice post today by Daniel Westheide called The Complexity Trap. Feels relevant.

Collapse
 
flaque profile image
Evan • Edited

There's never enough; they're all bad; they're all amazing.

Use Evergreen. 🌲

Collapse
 
rhymes profile image
rhymes

Ahaha :-D

That's another bummer with all these libraries. I don't use React, so Evergreen would be automatically discarded in an evaluation. You can't really consider a library built out of framework X if you use framework Y.

Collapse
 
c0il profile image
Vernet Loïc

Too many when you can't control the technical debt and it's constantly growing until your project become "legacy". 😢

Collapse
 
nickytonline profile image
Nick Taylor • Edited

This tweet seems relevant. Is this what inspired your post or just the repo you linked to?

Collapse
 
rhymes profile image
rhymes

No, it wasn't that, though I agree with both of them but I'm not sure it applies to the UI libraries for the major frameworks (after all different CSS frameworks have been giving us different options for quite some time).

I see the argument of diversification applied better to the numerous way of writing frontends that are popping up. From classic server side to SPAs to Elm to transpilers to whatever Flutter just previewed to using Web Assembly mixed to any of the options above :D