I’m coming around to a front end philosophy lately that shuns “all-in-one” component libraries entirely, because it’s a fantasy that never really plays out in reality. Take just tables for example; every component library has their own table implementation, and they all fall short in some fashion. Either they lack sufficient filtering, or their rendering performance nosedives with large datasets, or they enforce some kind of data structure that doesn’t work for you. So you end up pulling in a specialized table library and theming it to fit your needs. Now you have two redundant table components in your codebase, and it can be really unclear to new contributors which should be used where and why. Repeat ad nauseum for dropdowns, modals, etc. and all of the sudden the vast majority of your initial component library choice becomes dead weight.<p>Better to build your own simple primitives using Tailwind, (buttons, text, popovers, cards, and the like), then selectively pull in specialized components that solve one single problem thouroughly, and have widespread OSS support and usage.