> You're trying to build a fast and slim UI that's gonna be deployed on routers and possibly loaded on low-power devices? You better care about every single line that gets loaded on the device.

Unless you've gone out of your way to buy a (more expensive) part with less memory, your router will have enough memory to make 86.1Kb an utter irrelevancy; so will most of what were traditionally considered "low-power devices". Yes there are extreme cases where it matters, but we're talking about a vanishingly rare proportion of use cases.

> I'm not saying dependencies are always wrong. I'm also not saying it's always right. I'm saying why you need the dependency and the quality of the code it includes is important to consider, and knee-jerk reactions of "of course I'd use it" is hurting the profession more than the library reuse saves us currently.

I think this is backwards, and the knee-jerk reaction of "of course it's important and you need to carefully think about it" is what's holding back the industry. The overwhelming majority of the time, the right thing is to use the dependency; the best development practice is to default to using dependencies and reassess if and when it you hit an actual problem.

Assuming I'm going to need the complexity more than 1-2 times in my source code, I'm going to be writing my own abstraction. Which takes time, needs tests writing, and I am going to make a typo or other silly mistake somewhere.

Run into a couple of examples of such complexity, and the dependency is well worthwhile.

A jQuery that can be tree-shaken would be awesome, as there are parts I use regularly and others I have never used. Ironically the -lite bundle leaves outs parts I use frequently...

Just look at the cost-benefit. Typically internal code has a defect rate of around 1/1000 lines, so 10-15 lines is about 0.01 bugs. 86.1Kb of an established, widely used library is a cost that I can't meaningfully distinguish from zero.