3 ms·

I've gotten so jaded on these "batteries included! everything you'll ever need!" component libraries over the years. Inevitably you'll run into a component that

I've gotten so jaded on these "batteries included! everything you'll ever need!" component libraries over the years. Inevitably you'll run into a component that is half-baked or incompatible with your architecture, which forces you to install a 3rd party alternative. Then it happens again. And again... Eventually you're left pulling in this huge library with 2MB of CSS just for the four components you're still using from it. Then a new dev joins the team and gets to enjoy the confusion of "should i use $library component here? Or do we have another wrapper for it? or is there something else entirely being used for it?". Just avoid the hassle and stick with a curated list of well fleshed out individual components that are tested and have thousands of stars each. Create a barebones wrapper over it to match your design system, and call it a day.

smrq 3y ago
I've gotten jaded with that approach too. The same thing happens, just on an individual component scale. (The number of times I've gotten written into a corner with $dropdown_component is too damn high.) My pendulum has swung to do it all yourself with ample links in the source to other projects on GitHub for inspiration.
- deleted 3y ago
  [deleted]
TheCapeGreek 3y ago
I agree with you. But I think this is a symptom of a different problem: Building admin panels with UI tools instead of config-driven tools. While component libs like this can be used for consumer-facing UI, when we talk about "dashboards" it's also often backoffice admin panels. You shouldn't be reaching for hand-writing UI design & logic in that scenario. You should be looking for an admin panel interface tool. Laravel has these in spades: Nova, Backpack, and Filament are the big three. You write some code and some logic tied to it, and the tool creates the UI for you. This lets you get back to writing code for the actual customers instead of for business processes. These can be used for consumer facing panels too, but with less control over the design, they're not really intended for it. But the JS ecosystem insists on being fragmented, so everything is rewritten manually. "Batteries included" needs a lot more than just batteries (the UI components).

smrq 3y ago

I've gotten jaded with that approach too. The same thing happens, just on an individual component scale. (The number of times I've gotten written into a corner with $dropdown_component is too damn high.) My pendulum has swung to do it all yourself with ample links in the source to other projects on GitHub for inspiration.

deleted 3y ago
[deleted]

TheCapeGreek 3y ago

I agree with you. But I think this is a symptom of a different problem: Building admin panels with UI tools instead of config-driven tools. While component libs like this can be used for consumer-facing UI, when we talk about "dashboards" it's also often backoffice admin panels. You shouldn't be reaching for hand-writing UI design & logic in that scenario. You should be looking for an admin panel interface tool. Laravel has these in spades: Nova, Backpack, and Filament are the big three. You write some code and some logic tied to it, and the tool creates the UI for you. This lets you get back to writing code for the actual customers instead of for business processes. These can be used for consumer facing panels too, but with less control over the design, they're not really intended for it. But the JS ecosystem insists on being fragmented, so everything is rewritten manually. "Batteries included" needs a lot more than just batteries (the UI components).