Don't Pick the Wrong JS Library

The Wrong Tool Costs You

I’ve been developing projects of my own. I hope to ship them, and in today’s tech world shipping usually means a web app. That usually means a chunk of ECMAScript (or Typescript if you like consistency or typing). If you value your time and want to ship (Note: sometimes you have different goals), then you’re probably going to be reaching for a set of tools.

Typescript, Prettier, EsLint, Webpack, Vite - these tools come to mind and once you’ve built at least a few sites you’ll begin to accrue a go-to tool set. These kits and communities become part of your toolbox, and you’ll get familiar with their strengths, weaknesses, and the weird spots.

But what if you’re facing a challenge that you’ve never had to deal with?

How do you find something that fills a gap?

Honestly, it’s a slog and it’s probably going to take more time than you’d expect - but I’ll give you some of the ways I try to deal with finding it.

Context for selection

For the rest of this article, I’ll walk through selecting a package to solve a problem in a piece of code that I intend to ship, and I’ll just show some of my methods for discovering and discriminating packages.

There are lots of other valid contexts for selecting packages. One that should often come up is a need to learn a new piece of software. In that case the goal is to use that package. If you need supporting packages, find someone else’s examples and work off of them. If you’re “wanting to learn [React, Angular, Tailwind],” then the rest of this article doesn’t quite apply (sorry).

What Even

A lot of the time you need software that solves a problem in a domain that you’re not familiar with. It might be parsing, testing, graphics, whatever.

If you don’t have a tool, and you need to find one it’s hard to even look up

1. Google it

   Seriously, look it up

   If you skip this step, shame on you. Literally googling the question you have (“How do I draw images in javascript”, “how do I display graphs in javascript”, “how do I store a lot of data in javascript”) can lead you to a good starting point. It can be helpful to add more guidance to your query: advanced search can save you a lot of time (i.e. use :stackoverflow to get to stuff about fixing problems and having your question closed).

   Really, just try and see what you find, and give a time limit. Something like 30 minutes to try and find something. Once you find the first, or most popular package, find it on NPM and look for what’s related. If you can’t find anything, take a break and re-evaluate: do you need this, what’s the actual function, are there different ways to get this done.

   Heck, we’re in the world of AI; ask Phind or ChatGPT to enhance your search.

2. Find an OSS or example project that does the thing you’re looking at and back trace from there.

   If you’re really new to the domain it’s often better to take inspiration from another developer. If the developer is kind enough to share their code somewhere like GitLab or GitHub, then you’re in luck.

   The “nice” thing about ECMAScript is that all of the packages and dependencies for a project live in the package.json file, so if you can get to the source code and the dependencies, you can investigate use those same dependencies.

3. Start asking around

   I’ve never gotten to this step without some leads.

   But!

   If you do end up somewhere where you can’t find any leads, you gotta start asking other developers. If you really couldn’t find anything on StackOverflow you can always start asking there. Make sure you include some of your work, so you don’t immediately get closed out as a duplicate (and you’ll get closed out as a duplicate anyway)

   A good portion of the time, this is going to work for you - and that’s a good thing.

A or B, and Checking Your Work

If you have 2 great candidates, picking the “better one” is usually not easy.

NPM Trends

https://npmtrends.com/

This site never decides whether or not you should pick one package over another, but it can give you insight into which libraries are moving where. Rarely, this has been the deciding factor for me in picking a new tool. More often than not, it simply informed if this tool is a bespoke new thing, or if it’s even remotely popular.

Sometimes the NPM package with 100 downloads per month is the right tool. A lot of the time it’s not for a larger project.

Build a Toy

If you’re on the fence and your problem allows for a small demo example - use package A and package B.

Here, you’d evaluate whether or not the solution has any high-level sticking points. If candidate packages do have problem points, then it may be best to avoid those packages.

Toy examples aren’t an indicator of total success: it’s hard to test code.

RTFC: the last resort

When it comes right down to it, sometimes you have to read the f _ _ _ ing code. This is not ideal because it takes a long time to find the qualities that you are looking for and even worse it’s hard to figure out if the things you see in the code base and developer community even contribute to those qualities.

And remember, we’re really just trying to ship code, not evaluate packages.

I’ll summarize what I’m usually looking for in a package:

• User Adoption
• Ease of use
• Good Documentation
• Active Development

Roughly speaking, you can gauge adoption by the npm downloads (this is not an empirical measure for the popularity of a package). If a package has over 1M downloads, I’ll consider it “well supported” and I’d expect it to get questions and answers on StackOverflow.

Active Development is also easy: if the package was published recently then it’s probably active.

The “Good Documentation” and “Ease of Use” are where this gets hard. How else can you know if the documentation (if there is any), meets your needs? How else do you check to see if the library’s API is easy to work with than to… work with it?

The problem is that takes time, and it’s not easy to know if you’ll run into a problem farther down the pipeline.

So far there is no fix for this.

But that’s the ~fun~ challenge of working with code. Sometimes you just have to try it to know.

Now, Go Forth and Code

Analysis paralysis is real. First and foremost,

Create. Build. Rebuild

Code is an iterative process, and we cannot let picking the exact right tool get in the way of discovery.

Go out, make something, and learn something.