Gregory's ServerI am implementing a drag and drop file input in React for work, and my instinct was to build my own using the HTML5 drag & drop API stuff. I was curious and looked at our old implementation, which uses a library called react-dropzone to handle the drop zone stuff. It's 683kb unpacked? And yes, it supports many configurations of drag & drop but our app only needs 1 configuration. Why introduce a huge blackbox dependency that wraps the browser API when you could just... use the browser API...
 10 comments
 @darius i wonder if it's for backwards compatibility with older browsers but more likely it's just bloat @muffinista I checked it's not -- it's really about providing toggleable features for lots of different UX edge cases @darius yeah that's a bummer. i had a similar issue lately with toast/notification libraries. they're all huge! i wrote one that's ~30 lines of css and js  @darius a lot of people i’ve worked with truly only see cost in one way: how long will it take to implement this feature it is misery i’m glad you’re considering this stuff! if only bc it heartens me to know all projects aren’t equally myopic @mood haha yeah. I mean I am reimplementing old code from the ground up so the N hours of implementation time that this library saved the devs 2 years ago is turning into ~4N now. (And yeah I get that sometimes you need to ship something NOW and sometimes that means you download a thing that does the thing. But also this particular component could have been made in... idk ~3 hours?)  @darius Web standards change all the time and people still use ancient browsers that don't support them, so people build their own "standards" as libraries which try to account for all of this...which is cool in theory except these web dev libraries seem to rise and fall just as often as the standards they're trying to replace....IMO, in the end you often just trade one big, constantly shifting pile of bloat for another... @admin right, that's the thing! I used to be a "use a library, the library will update so I don't have to" and that is just... almost never true in practice. I've come back around to "at least my own code was written by me so I can fix it" @darius Yup! On the one hand, computing is entirely built upon layers of abstraction, "use the library" is a very core concept of software engineering. On the other hand...some libraries ultimately aren't providing much abstraction in the end, and you've gotta balance that against the additional resource consumption, the loss of control, the effort of learning the library....a lot of libraries feel to me like they're merely a fraction of a true abstraction layer and therefore not worth it |
If my component was
1) very complicated, needing to handle lots of different state
2) central to the UX of our app
then I would absolutely use this well-tested, widely-used library. It would be worth the cost in both added external dependency and file size. But the library gets 1 million downloads a week and I bet most of those are use cases where this is sheer overkill.