5 ms·

I almost always opt for a library as long as 1. It is still alive 2. It is on GitHub so I can easily read the source and look for issues 3. People star it 4

I almost always opt for a library as long as 1. It is still alive 2. It is on GitHub so I can easily read the source and look for issues 3. People star it 4. It has traction ie >10k downloads preferably >50k 5. It occupies a name that makes sense ie I’d rather trust using “redux-immutable” than “steel-porcupine”, since it unofficially lends itself to the “vetted one true solution” 6. Then I look at the source quickly and make sure it looks well done under the hood 7. Finally, if it’s particularly confusing, I might run a quick google check to see if there’s blogs about it on the internet explaining how to use the advanced features and check the date on the blogs (1-2 years ago = good, it’s mature) If any of the above are too dicey and there’s no good options, I put the relevant code in a top level folder called “modules” (or otherwise) with the intention that in the future I might get to delete it if the package ecosystem gets more mature in that space. Sometimes I even get to polish those files up and actually publish them.

danenania 8y ago
Considering traction makes sense, but also remember that every popular library had to start somewhere. If there are no red flags (like a backlog of issues or lack of documentation) and it looks like it could solve your problem, don't be afraid have a look through the code and verify yourself that it's well built, then become an early adopter. I've come across plenty of 10-star libs on Github that solve problems extremely well.
sloonz 8y ago
> 3. People star it > 4. It has traction ie >10k downloads preferably >50k Why ? Your home-made code probably don't check those boxes.
- jsmeaton 8y ago
  Because an Unmaintained library is worse than one you write yourself because bugs are much harder to understand and fix.
  - majewsky 8y ago
    You imply that you're still going to understand your code one year later. While this is a favorite fantasy of all programmers, it's usually false. Also, if you're in a team, the person running into the bug is likely not you, so it's foreign code for them anyway.
    - jsmeaton 8y ago
      I was being brief because I was leaving work so I’ll expand a bit. An unmaintained library is usually more difficult to fix because fixes are no longer committed back or released. At that point you can choose to vendor and maintain your own copy, or replace it with something else. And at either of those points you’re no longer in context. My point wasn’t really geared at debugging a piece of code. A library, my own, or a coworkers are roughly comparable. The cost to fix is a lot higher in a library though. It’s not a universal rule, despite the way I originally phrased it.
      - V-2 8y ago
        I think there is also certain negative selection bias in the sense that people are more likely to stop maintaining libraries that were badly designed / problematic to begin with. That's why I tend to be more sceptical than average when it comes to "orphaned" projects.
  - jwdunne 8y ago
    I've had many a struggle with this. On the flip side, I have found libraries that are unmaintained and are pleasant enough to understand. I've forked those and used them, happy that: 1. I can quickly fix any bugs that I face 2. Someone else can make use of my maintenance.
- bausshf 8y ago
  I agree with 3, not necessarily 4. The amount of people who uses a product does not determine is quality. However stars can determine to an extend whether it's a project worth looking at or not.
- marssaxman 8y ago
  My home-made code will probably just do the specific thing I need it to do, and not all of the other things the library has been generically designed for.
eeZah7Ux 8y ago
> 1. It is still alive A mature project that just works does not need new commits.
- deleted 8y ago
  [deleted]
- mort96 8y ago
  True, a project with a bunch of stars and ownloads and whatnot and no open issues and pull requests can be perfectly fine even if the last commit was a few years ago. However, if the last commit was years ago, and issues and pull requests have been piling up without getting any attention, that's probably a bad sign.
- bartread 8y ago
  That's true, but whether a project is alive or not goes beyond whether people are committing code. E.g., - If you file a bug report does the bug get fixed? Do you even get a response? - If you ask for help from the community, do you get it?
- aetherspawn 8y ago
  You can determine that by ie looking at the issues list and eyeballing whether there are pages of issues with no comments on them. Not necessarily whether there are commits or not.
endymi0n 8y ago
From a decade of software engineering and architecture I'd say these are some excellent guidelines for when to choose a library. Let me follow up with a collection of the cases where I'd absolutely stay away from libraries: 1. Your standard library can do it. Whatever you do, RTFM, learn your language inside out and prefer the standard library for whatever you do, even if it looks a little worse — especially if it's not more than 50% more code than using a library for convencience functions. This already goes 80% of the way to prevent "left-pad"-like disasters. 2. Everything that is your core business logic. Don't succumb to the fascination of rule engines and state machine builders. Just write that damn code yourself, future you will be way happier for it. 3. If you're sure that you'll never need more than 10-20% of a library, but eventually will need something considerably different starting from there. This may be grounds for justifying building your own one. If you do that and it doesn't give your business a unique edge, consider open sourcing it from the start. 4. If in doubt, rather stay away from big, fat frameworks until they give you a really big edge (like in Frontend development) or you tend to do a lot of rinse-and-repeat stuff. They tend to solve a lot of your problems, but rot fast and you have to continuously keep up with the Kardashians.
- icebraining 8y ago
  Regarding (1), can't say I agree; by all means, know your stdlib well, but if you still wonder if you need a library, and there's one with a lot of traction, I'd just use it. left-pad is a red herring - the problem there was poor dependency management, not the use of the library itself.

danenania 8y ago

Considering traction makes sense, but also remember that every popular library had to start somewhere. If there are no red flags (like a backlog of issues or lack of documentation) and it looks like it could solve your problem, don't be afraid have a look through the code and verify yourself that it's well built, then become an early adopter. I've come across plenty of 10-star libs on Github that solve problems extremely well.

sloonz 8y ago

> 3. People star it > 4. It has traction ie >10k downloads preferably >50k Why ? Your home-made code probably don't check those boxes.

jsmeaton 8y ago
Because an Unmaintained library is worse than one you write yourself because bugs are much harder to understand and fix.
- majewsky 8y ago
  You imply that you're still going to understand your code one year later. While this is a favorite fantasy of all programmers, it's usually false. Also, if you're in a team, the person running into the bug is likely not you, so it's foreign code for them anyway.
  - jsmeaton 8y ago
    I was being brief because I was leaving work so I’ll expand a bit. An unmaintained library is usually more difficult to fix because fixes are no longer committed back or released. At that point you can choose to vendor and maintain your own copy, or replace it with something else. And at either of those points you’re no longer in context. My point wasn’t really geared at debugging a piece of code. A library, my own, or a coworkers are roughly comparable. The cost to fix is a lot higher in a library though. It’s not a universal rule, despite the way I originally phrased it.
    - V-2 8y ago
      I think there is also certain negative selection bias in the sense that people are more likely to stop maintaining libraries that were badly designed / problematic to begin with. That's why I tend to be more sceptical than average when it comes to "orphaned" projects.
- jwdunne 8y ago
  I've had many a struggle with this. On the flip side, I have found libraries that are unmaintained and are pleasant enough to understand. I've forked those and used them, happy that: 1. I can quickly fix any bugs that I face 2. Someone else can make use of my maintenance.
bausshf 8y ago
I agree with 3, not necessarily 4. The amount of people who uses a product does not determine is quality. However stars can determine to an extend whether it's a project worth looking at or not.
marssaxman 8y ago
My home-made code will probably just do the specific thing I need it to do, and not all of the other things the library has been generically designed for.

eeZah7Ux 8y ago

> 1. It is still alive A mature project that just works does not need new commits.

deleted 8y ago
[deleted]
mort96 8y ago
True, a project with a bunch of stars and ownloads and whatnot and no open issues and pull requests can be perfectly fine even if the last commit was a few years ago. However, if the last commit was years ago, and issues and pull requests have been piling up without getting any attention, that's probably a bad sign.
bartread 8y ago
That's true, but whether a project is alive or not goes beyond whether people are committing code. E.g., - If you file a bug report does the bug get fixed? Do you even get a response? - If you ask for help from the community, do you get it?
aetherspawn 8y ago
You can determine that by ie looking at the issues list and eyeballing whether there are pages of issues with no comments on them. Not necessarily whether there are commits or not.

endymi0n 8y ago

From a decade of software engineering and architecture I'd say these are some excellent guidelines for when to choose a library. Let me follow up with a collection of the cases where I'd absolutely stay away from libraries: 1. Your standard library can do it. Whatever you do, RTFM, learn your language inside out and prefer the standard library for whatever you do, even if it looks a little worse — especially if it's not more than 50% more code than using a library for convencience functions. This already goes 80% of the way to prevent "left-pad"-like disasters. 2. Everything that is your core business logic. Don't succumb to the fascination of rule engines and state machine builders. Just write that damn code yourself, future you will be way happier for it. 3. If you're sure that you'll never need more than 10-20% of a library, but eventually will need something considerably different starting from there. This may be grounds for justifying building your own one. If you do that and it doesn't give your business a unique edge, consider open sourcing it from the start. 4. If in doubt, rather stay away from big, fat frameworks until they give you a really big edge (like in Frontend development) or you tend to do a lot of rinse-and-repeat stuff. They tend to solve a lot of your problems, but rot fast and you have to continuously keep up with the Kardashians.

icebraining 8y ago
Regarding (1), can't say I agree; by all means, know your stdlib well, but if you still wonder if you need a library, and there's one with a lot of traction, I'd just use it. left-pad is a red herring - the problem there was poor dependency management, not the use of the library itself.