[lmm]

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

Yes, absolutely. That's a total no-brainer.

> Hidden complexity you don't control is the most expensive kind I think.

There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your custom implementation of whatever it was than in jQuery.

[capableweb]

> > Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

> Yes, absolutely. That's a total no-brainer.

That's what we've been thought but it's not a no brainer at all. Context matters, but you disregard it and only focus on the lines of code, just as the author of the comment you respond to is saying people do.

You're building a marketing page that's not gonna be updated after completed and only gonna be valid for X days? Sure, the code doesn't matter.

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.

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.

[lmm]

> 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.

[petecooper]

>> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? >Yes, absolutely. That's a total no-brainer.

I'm curious - would you be able to elaborate, please? Thank you.

[porker]

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...

[lmm]

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.