7 ms·

This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity

by jart 6y ago

This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.

jamiesonbecker 6y ago
> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.
- franklyt 6y ago
  Actually, it's called abstraction, as a technical point.
  - jamiesonbecker 6y ago
    Good point. This is what I was referring to: https://en.wikipedia.org/wiki/Encapsulation_(computer_programming) https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...
- userbinator 6y ago
  In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.
  - jamiesonbecker 6y ago
    > In the real world... From experience... Does jQuery (est. 2006) have more bugs in it than your code?
  - scubbo 6y ago
    Have fun implementing everything from scratch in assembly.
  - quattrofan 6y ago
    As has been seen many times recently third party libraries are a major attack vector for the bad guys.
  - nicoburns 6y ago
    > In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. jQuery's not a very good example of this though. It's one of the most widely used, and hence most tested and least buggy pieces of software out there. Nowadays the web APIs are pretty solid, but back in the IE6/7/8 days the jQuery API was a lot less buggy than using the built in APIs directly.
  - donapieppo 6y ago
    > In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to To me this seems a comment that only stands for one-developer projects.
lmm 6y ago
> 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.
- petecooper 6y ago
  >> 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 6y ago
    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 6y ago
    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.
- BigJono 6y ago
  > > Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? > Yes, absolutely. That's a total no-brainer. Are you taking the piss?
- capableweb 6y ago
  > > 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.
arp242 6y ago
It's 77k for the latest version, and after compression it's ~32k. It's really not all that large. You can also reduce this to about ~27k if you exclude some less-commonly used things like animations, shortcuts, etc. JS people be like: "86K jQuery dependency is wasteful!" Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"
- toper-centage 6y ago
  That's a very good point. We have been hating JQuery for so long, that we didn't notice that it's size when down while app size inflation grew exponentially. 15 years ago loading 50kb of bloat was reason to worry, today no one bats an eye.
- varrock 6y ago
  I just want to mention that you are replying to someone who never said anything about SPA. They made an interesting point about trade offs.
  - arp242 6y ago
    It describes the general attitude of the community; go to /r/javascript or /r/webdev and mention jQuery (...if you're brave enough) and you'll get those kind of responses, often accompanied that you should be using "modern tools". Then mention multi-megabyte JS bloat and you'll get those kind of responses as well, in the very same thread, and the very same people will be argueing both points at the same time.
    - necovek 6y ago
      While your points might be true, you are arguing how there are hypocritical and dishonest people somewhere else. You are also putting a heavy burden of proof on your readers: it generally sounds implausible that exactly the same people would complain about <100kiB being bloat and >1MiB not for the same use-case, but I am not going to go and fact-check that (with the implausibility of the claim, I would expect you to give direct pointers yourself or will simply distrust your claim).
viseztrance 6y ago
Lines of code is a bad metric for complexity. Jquery is a thin wrapper over javascript, whereas React has a comparable size but is a significantly higher level abstraction.
bryanrasmussen 6y ago
>is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? I don't actually use jQuery any more but obviously if you are using it, you are saving the 10-15 lines every time you use one of these methods, not 10-15 lines in your whole application. I have a hard time believing that the savings of code lines will not be close to the weight of the dependency in any medium sized company codebase.
spiralx 6y ago
A vendor dependency that's almost certainly locally cached already if you use one of the common CDNs for serving jQuery - ajax.googleapis.com, cod.jquery.com, cdnjs.cloudflare.com or cdn.jsdelivr.net.
- M2Ys4U 6y ago
  Browsers are now separating out caches per origin so that benefit has gone away.
nickjj 6y ago
> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? There's projects like https://umbrellajs.com/ https://umbrellajs.com/ which are very similar to jquery's APIs for DOM manipulation and it's only 2.5kb gzipped. IMO it's a nice balance between having a convenient API without bringing in the world. If I could write 2-5x less code and it's easy to remember I would make that trade off every time.
notjustanymike 6y ago
It's never just 10-15 lines, and I'll always take 86Kb of a properly tested, production environment validated, properly documented, community supported, cross-browser library over the one-off functions I frequently squash in code reviews.

by jart 6y ago

jamiesonbecker 6y ago

> Hidden complexity you don't control is the most expensive kind I think. That's called encapsulation. :) Seriously, encapsulating complexity is the foundation of most programming paradigms.

franklyt 6y ago
Actually, it's called abstraction, as a technical point.
- jamiesonbecker 6y ago
  Good point. This is what I was referring to: https://en.wikipedia.org/wiki/Encapsulation_(computer_programming) https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...
userbinator 6y ago
In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.
- jamiesonbecker 6y ago
  > In the real world... From experience... Does jQuery (est. 2006) have more bugs in it than your code?
- scubbo 6y ago
  Have fun implementing everything from scratch in assembly.
- quattrofan 6y ago
  As has been seen many times recently third party libraries are a major attack vector for the bad guys.
- nicoburns 6y ago
  > In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better. jQuery's not a very good example of this though. It's one of the most widely used, and hence most tested and least buggy pieces of software out there. Nowadays the web APIs are pretty solid, but back in the IE6/7/8 days the jQuery API was a lot less buggy than using the built in APIs directly.
- donapieppo 6y ago
  > In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to To me this seems a comment that only stands for one-developer projects.

lmm 6y ago

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

petecooper 6y ago
>> 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 6y ago
  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 6y ago
  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.
BigJono 6y ago
> > Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? > Yes, absolutely. That's a total no-brainer. Are you taking the piss?
capableweb 6y ago
> > 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.

arp242 6y ago

It's 77k for the latest version, and after compression it's ~32k. It's really not all that large. You can also reduce this to about ~27k if you exclude some less-commonly used things like animations, shortcuts, etc. JS people be like: "86K jQuery dependency is wasteful!" Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"

toper-centage 6y ago
That's a very good point. We have been hating JQuery for so long, that we didn't notice that it's size when down while app size inflation grew exponentially. 15 years ago loading 50kb of bloat was reason to worry, today no one bats an eye.
varrock 6y ago
I just want to mention that you are replying to someone who never said anything about SPA. They made an interesting point about trade offs.
- arp242 6y ago
  It describes the general attitude of the community; go to /r/javascript or /r/webdev and mention jQuery (...if you're brave enough) and you'll get those kind of responses, often accompanied that you should be using "modern tools". Then mention multi-megabyte JS bloat and you'll get those kind of responses as well, in the very same thread, and the very same people will be argueing both points at the same time.
  - necovek 6y ago
    While your points might be true, you are arguing how there are hypocritical and dishonest people somewhere else. You are also putting a heavy burden of proof on your readers: it generally sounds implausible that exactly the same people would complain about <100kiB being bloat and >1MiB not for the same use-case, but I am not going to go and fact-check that (with the implausibility of the claim, I would expect you to give direct pointers yourself or will simply distrust your claim).

viseztrance 6y ago

Lines of code is a bad metric for complexity. Jquery is a thin wrapper over javascript, whereas React has a comparable size but is a significantly higher level abstraction.

bryanrasmussen 6y ago

>is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? I don't actually use jQuery any more but obviously if you are using it, you are saving the 10-15 lines every time you use one of these methods, not 10-15 lines in your whole application. I have a hard time believing that the savings of code lines will not be close to the weight of the dependency in any medium sized company codebase.

spiralx 6y ago

A vendor dependency that's almost certainly locally cached already if you use one of the common CDNs for serving jQuery - ajax.googleapis.com, cod.jquery.com, cdnjs.cloudflare.com or cdn.jsdelivr.net.

M2Ys4U 6y ago
Browsers are now separating out caches per origin so that benefit has gone away.

nickjj 6y ago

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? There's projects like https://umbrellajs.com/ https://umbrellajs.com/ which are very similar to jquery's APIs for DOM manipulation and it's only 2.5kb gzipped. IMO it's a nice balance between having a convenient API without bringing in the world. If I could write 2-5x less code and it's easy to remember I would make that trade off every time.

notjustanymike 6y ago

It's never just 10-15 lines, and I'll always take 86Kb of a properly tested, production environment validated, properly documented, community supported, cross-browser library over the one-off functions I frequently squash in code reviews.