Nowadays you would just "npm install drag-and-drop" but back then you often had to hand-roll solutions.
If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long, not to mention the absolute nightmare that testing something like this with a proper framework and accompanying testing library.
> If anyone can dig up an ancient library on GitHub for drag-and-drop back in those days, I'd imagine it would be several thousand lines long,
I bet, the JS devs who do write code overcompensate for the ones who can only stitch together libraries. I suppose because the expectation is that the library consumer is incapable of writing their own code extending it, so the library itself must support every possible combination of use cases for a million different users, even though the code any individual consumer actually needs is more like 100 loc.
> What the hell do you need a library for?
Think of a grid of cards, and all the possible drag, hover, and drop state transitions it can be in with any other card, and the animations required to make it look nice
Now also consider that you need to persist the final state on the backend, and handle things like rejection, cancellation, failed updates/errors.
It becomes a massive state chart and web of complexity