Guidelines for choosing React Libraries
After publishing my previous article tracking React Libraries worth talking about, a few people asked me how I decide which library to use in my own projects.
Truth is, I don't have a single hard and fast rule, but rather a feeling that comes from looking at how a library stacks up against a set of quick checks that I've developed over the years of being burned by dodgy libraries.
I've also been asked this several times over the years as an interview question for frontend developer roles. I've heard different answers every time I asked the question back to the interviewer - keep in mind that some teams care about different things, and you might have to decide for yourself.
Also, if you strongly disagree with these points, feel free to write up an article, and share it with me! I'm genuinely interested in what other developers look at when picking their libraries.
Docs
One of the first things I check before installing a library is the documentation.
- Are the docs up to date?
- Are they versioned (if the maintainers update the library over time, can I go back and still read the docs from the version I use)?
- Are they detailed enough that I can figure out how to use the library for my use case?
Issues
I also check GitHub Issues to see if the library still works, and to see how active the maintainers are. Not so much to outright reject libraries with inactive maintainers, but more to guide my expectations.
- Will I have to support myself/contribute before I can even use the library?
- Are there glaring open issues that I might care about, such as the library not working any more, or not supporting certain use cases.
Browser/Mobile Compatibility
Especially in the case of Component/UI libraries, I want to know the extent of browser and mobile support. I wouldn't always check this, but checking GitHub Issues for problems with browsers can save you pain later.
Unfortunately there are still end-users out there that still want IE11 to be supported (particularly government agencies), so some teams may wish to check for Internet Explorer compatibility when picking libraries.
Library size
If a library is small enough, or I only need a small portion of the library, I might not even install it with yarn or npm. I'll just copy the function into a utils folder and write my own tests for it.
In the end, we're hunting for functionality, and I'd prefer to avoid writing fresh code where possible. If a library exists, you may as well use it rather than writing your own from scratch.
Side note: I witnessed the cost of ignoring this, particularly with SWR - a team I worked with implemented their own version, experienced and fixed the same bugs/pitfalls, and learned the same lessons in state and cache management. Easily hundreds of hours that could have been saved with a yarn add swr/npm install swr.
On the other hand, is it too big? Unless I'm building a super quick prototype, I will always compare libraries in Bundlephobia, and prefer the smaller library (and consider the other points in this article).
Examples
If I have to choose between two libraries, (and all else being equal), I'd pick the one with examples. Bonus points for using CodeSandbox or providing running examples that I can copy paste out of the repo.
If you want to see how well this can be done in the React ecosystem, see Razzle and React Hook Form.
Popularity
I'd be lying if I said popularity didn't bias my decision, so I've included it in this article. That being said though, I wouldn't shy away from being an early adopter of a library if it solved a problem I was looking to fix.
There are a few means of understanding how popular a library is:
Number of stars on GitHub, combined with "Used by" on GitHub
(In my opinion) the number of stars alone will just tell you how many blog posts people write about a library, and how famous the maintainers are. Combining the number of stars with the number of projects that use the library as a dependency gives you a better understanding of whether it's actually used.
Weekly downloads on npm
It's worth keeping in mind that this number is not always bulletproof.
For example,
@testing-library/reactrecently beatenzymeon weekly downloads, however@testing-library/reactis now downloaded as part of create-react-app, regardless of whether it's used or not.
Summary
In conclusion, this article was an attempt at explaining what I look at (often without even realising) when deciding to use a library.
Different developers will have different opinions and criteria - we haven't all had the same career, we've all seen and experienced different things to shape what we value.
If you're just starting out in the frontend, hopefully this article gives you guidance in terms of what to look for.
(Shameless plug for the useEffect book I wrote below)
Tired of infinite re-renders when using useEffect?
A few years ago when I worked at Atlassian, a useEffect bug I wrote took down part of Jira for roughly one hour.
Knowing thousands of customers can't work because of a bug you wrote is a terrible feeling. To save others from making the same mistakes, I wrote a single resource that answers all of your questions about useEffect, after teaching it here on my blog for the last couple of years. It's packed with examples to get you confident writing and refactoring your useEffect code.
In a single afternoon, you'll learn how to fetch data with useEffect, how to use the dependency array, even how to prevent infinite re-renders with useCallback.
