11 ms·

I went down this path very recently as a React newbie, for the exact reasons you stated. It looked like I'd be able to save a bunch of time, and I'm sure I did.

by hi_hi 2y ago

I went down this path very recently as a React newbie, for the exact reasons you stated. It looked like I'd be able to save a bunch of time, and I'm sure I did. But I also _spent_ a bunch of time as soon as I needed something slightly different to OOTB (or sometimes just wanted to understand how a thing worked better). At that point I ended up digging through Radix code, React library documentation where there were frequently multiple ways of doing the same thing and I had no idea which was "best". I had to delve into some of the more complex (to me, as a newbie) patterns like forwardRef. And this was all for a very trivial site/app that needed some form interactions. My takeaway at the end was, I'd learnt a bunch of new stuff, which was the point, but that was all workarounds for dealing with the complexities introduced by the tools which were meant to simplyfy my life. Perhaps for large projects with multiple devs, they bring efficiencies of scale. I think for my next solo project I'm trying Rails or Django with htmx.

klaussilveira 2y ago
I understand that sentiment, although in an opposite away: for large projects with multiple devs, I'd prefer something like Rails or Django, precisely because they are battle-tested with a lot of official documentation. Things are done in one specific way and the team can just agree to whatever the framework recommends. And there are clear guidelines for pretty much everything. However, in solo projects, I want to spin something up quickly. I don't want to spend my scarce weekend time designing yet another date time picker. Or having to write hackish CSS to try and make whatever time picker library I chose to match the CSS of Bootstrap. And then everything falls apart because some other library does not fit into the overall style (looking at you DataTables). In React land, I don't have to worry about this. I just throw components together, link it to my API where the show real is, and call it a day. UIs are just UIs. They should be plug and play. So much time is wasted redesining data grids and data tables and pickers and filters for the 1000th time.

by hi_hi 2y ago

klaussilveira 2y ago

I understand that sentiment, although in an opposite away: for large projects with multiple devs, I'd prefer something like Rails or Django, precisely because they are battle-tested with a lot of official documentation. Things are done in one specific way and the team can just agree to whatever the framework recommends. And there are clear guidelines for pretty much everything. However, in solo projects, I want to spin something up quickly. I don't want to spend my scarce weekend time designing yet another date time picker. Or having to write hackish CSS to try and make whatever time picker library I chose to match the CSS of Bootstrap. And then everything falls apart because some other library does not fit into the overall style (looking at you DataTables). In React land, I don't have to worry about this. I just throw components together, link it to my API where the show real is, and call it a day. UIs are just UIs. They should be plug and play. So much time is wasted redesining data grids and data tables and pickers and filters for the 1000th time.