3 ms·

> Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well that's where modern bundl

> Using a library for every little function, or worse, adding a huge library for a couple of function calls make my hairs go up. Well that's where modern bundler steps in - who cares if you throw the unnecessary cruft away during build process? Except in Python where a dependency might uninstall your desktop GUI and switch the init system, perhaps.

bayindirh 2y ago
The problem with this approach is not shipping unused functions at the end. Pruning them is an old practice. The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull. Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins. Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.
- throwaway11460 2y ago
  That's why we use Semver, at least in the Node land. A security fix should be a patch, at most minor version bump - API/behavior shouldn't change.
  - bayindirh 2y ago
    This doesn't change the fact that some security fixes forces behavioral changes, and semver doesn't protect you against that. You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.
barkbyte 2y ago
Dependencies can also do that in node with post install hooks (or in rust with build.rs even if you don’t call into them, I think)
edflsafoiewq 2y ago
The dev who you made download and build all those deps just to throw them away for one. Not super fond of the attitude that efficiency for the end user is a necessary evil... but a dev can be expected to endure any indignity.
- throwaway11460 2y ago
  What about the dev who is making the library for their own purposes, they don't matter? Be thankful for the opportunity to use their work for free; you can do your own thing if you don't like theirs.
  - edflsafoiewq 2y ago
    By that argument you can never criticize anything, so what's the point of even talking about how you should or should not code?
    - throwaway11460 2y ago
      Yes, you can't criticize that somebody made a big library - you have no idea why, how and under what circumstances it was made. Even if the only reason is that the author doesn't find it fun to maintain a bunch of libraries, that's still a valid reason. It's actually exactly that most of the time - it's a hobby, not a job to them. They probably maintain few dozen microservices at work, why bring it home too? In other cases you have resource constraints, cost/benefit optimization, etc. You can say you'd prefer a bunch of smaller more focused libraries, but criticizing that big one is wrong, especially if you got it for free including the source and a license to distribute and modify it. And this has nothing to do with how you should or should not code, there's no definite way how everyone should code; some prefer batteries-included frameworks and some prefer small focused pieces - it's an opinion more than a fact that small library is better. But even if not, people are free to share their bad work and you are free to pass on it, provide suggestions or patches - but criticizing it is entitled. BTW it's funny to argue that you should be able to criticize a big library for being too big right under a discussion about dependency version requirement hell. One big library that includes everything would alleviate that pain - perhaps that's what the authors were looking to fix. As I said, this is an opinion, not fact.

bayindirh 2y ago

The problem with this approach is not shipping unused functions at the end. Pruning them is an old practice. The problem is inclusion of that much libraries creates a dependency hell, because a higher level library pulls in approximately 5 more libraries which are generally shared amongst other libraries you potentially pull. Library A updates its' dependency to library C to a new, more recent minimum, but library B depends on C's behavior which is recently changed. Hence A requires C > v3, but B requires C==v2. Then the fun begins. Bonus points for having a serious CVE/RCE as a reason for updating C to v3 in the first place.

throwaway11460 2y ago
That's why we use Semver, at least in the Node land. A security fix should be a patch, at most minor version bump - API/behavior shouldn't change.
- bayindirh 2y ago
  This doesn't change the fact that some security fixes forces behavioral changes, and semver doesn't protect you against that. You fix the bug, and the behavior changes, because your design was wrong in the first place. Now there is at least one library which depends on that behavior so bad, so they can't change their dependency chain in two days.

barkbyte 2y ago

Dependencies can also do that in node with post install hooks (or in rust with build.rs even if you don’t call into them, I think)

edflsafoiewq 2y ago

The dev who you made download and build all those deps just to throw them away for one. Not super fond of the attitude that efficiency for the end user is a necessary evil... but a dev can be expected to endure any indignity.

throwaway11460 2y ago
What about the dev who is making the library for their own purposes, they don't matter? Be thankful for the opportunity to use their work for free; you can do your own thing if you don't like theirs.
- edflsafoiewq 2y ago
  By that argument you can never criticize anything, so what's the point of even talking about how you should or should not code?
  - throwaway11460 2y ago
    Yes, you can't criticize that somebody made a big library - you have no idea why, how and under what circumstances it was made. Even if the only reason is that the author doesn't find it fun to maintain a bunch of libraries, that's still a valid reason. It's actually exactly that most of the time - it's a hobby, not a job to them. They probably maintain few dozen microservices at work, why bring it home too? In other cases you have resource constraints, cost/benefit optimization, etc. You can say you'd prefer a bunch of smaller more focused libraries, but criticizing that big one is wrong, especially if you got it for free including the source and a license to distribute and modify it. And this has nothing to do with how you should or should not code, there's no definite way how everyone should code; some prefer batteries-included frameworks and some prefer small focused pieces - it's an opinion more than a fact that small library is better. But even if not, people are free to share their bad work and you are free to pass on it, provide suggestions or patches - but criticizing it is entitled. BTW it's funny to argue that you should be able to criticize a big library for being too big right under a discussion about dependency version requirement hell. One big library that includes everything would alleviate that pain - perhaps that's what the authors were looking to fix. As I said, this is an opinion, not fact.