from Curated list of framework component libraries for UI styles/toolkit
For further actions, you may consider blocking this person and/or reporting abuse
Read next
Node.js is not a JavaScript framework
Sospeter Mong'are -
Nomeação de variáveis baseada no clean code
Gean ferreira -
🚀 Why Next.js Is an All-Time Game Changer for Web Development: A Technical Perspective 🛠️
Hamza Khan -
useEffect must not return anything besides a function, which is used for clean-up.
kk1123 -
Top comments (15)
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:
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
Every library out there. Vue rings a bell.
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.
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.
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.
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.
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.
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
CV driven development?
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.
There's never enough; they're all bad; they're all amazing.
Use Evergreen. 🌲
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.
Too many when you can't control the technical debt and it's constantly growing until your project become "legacy". 😢
This tweet seems relevant. Is this what inspired your post or just the repo you linked to?
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