Comment by aetherspawn | Hacker News Reader

Comment by aetherspawn | Hacker News Reader

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.

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.

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.

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.

> 3. People star it

> 4. It has traction ie >10k downloads preferably >50k

Why ? Your home-made code probably don't check those boxes.

Because an Unmaintained library is worse than one you write yourself because bugs are much harder to understand and fix.

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.

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.

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.

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.

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.

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.

> 1. It is still alive

A mature project that just works does not need new commits.

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.

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?

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.

Reply on news.ycombinator.com