Which JavaScript Library Should I Pick?

We live in a world where we encourage our fellow developers to share and open source their solutions, especially in the land of JavaScript libraries. Just look at something like microjs.com to get an idea of how many different solutions there are for the same problem. For some problems, like picking a date, there are so many libraries in the space that we have articles rounding up the "Top 15 jQuery DatePickers", trying to narrow down the space for us.

But too many choices can be a paralyzing thing for us mere humans. How do we know which one is best? What if we make the wrong choice?

Well, listen: I don't think there's often a "best choice" in web development, and I think there are better ways to spend your time than constantly upgrading to the latest and greatest library. But I do think there are better choices than others, and I wanted to share my strategy for picking a library when I'm faced with a wall of choices. (Let's just pretend that "write our own" isn't an option, for simplicity's sake, shall we?)

Since a JS library is often used when developing a user-facing product, I think of the strategy as satisfying two audiences: the developers that must code and maintain the use of the library, and the users that will interact with it.

Will it be a good developer experience?

• Well documented: Seems like a no-brainer, of course, but it should be easy to find a reference of function signatures, to find demos of actual usage, and to find a more narrative how-to-use guide. If a library proclaims "we don't need docs, just read the code!", I will interpret it as "we do not care about you, go away."
• Flexible: Sure, you might think the demo looks great - but you will likely use a library in a slightly or completely different way than they designed it. Look for signs of extendibility - Is it easy to send in configuration options? Is there a documented plugin architecture? Does it trigger many events that you could hook your code into? My most painful experiences have been attempting to extend libraries that weren't built with that in mind, which is why it's now one of the first things I look for.
• Responsive community: You *will* have questions. You *will* encounter bugs. And ideally, you'll be able to figure them out with developers, whether that's the maintainers or users. To get a feel for the community, take a look at:
  • Number of forks: Lots of forks (or stars) means there are at least a lot of developers that cared enough to fork the library. That doesn't mean they'll help you, of course. For context, Bootstrap has 17,079 forks (which I believe makes it the most forked repo on Github), Backbone has 2,914, Select2 has 1,141, and a little lib of mine, lscache, has a whopping 41.
  • Number of issues: Are there many open issues? That might be a sign that there's not a community effort around responding and closing issues. It can also mean it's just a very popular project with a lot of ideas for improvement, so continue on to the next point.
  • Vibe on issues: Read through a few issues and pull requests. Are the maintainers receptive to feedback? Do they answer usage questions? Do you get a positive or negative vibe from the conversations on them?
  • External community: Are questions about the library answered on StackOverflow? Are there libraries that piggyback off of the project? Many micro libraries won't be big enough to have a visible external community, but bigger ones like Modernizr or Backbone have significant ones, and that's a big motivation for using them.
• Actively maintained: Browsers change. Libraries that once worked, can suddenly stop working, because they relied on some quirk of the browser that changed. This is specially true of HTML5 shims and polyfills, because browsers are frequently releasing new versions with evolving implementations of the HTML5 elements.
• Future thinking: If it's an HTML5 shim, prefer a polyfill - a shim that mimics the API. That way, theoretically, when all your users were using browsers that supported the technology, you'd be able to stop using the library entirely, with no change to your code at all.
• Tested: All your code should be tested, and the JS libraries that you bring in are no exception. If they have a test suite, then we can feel confident that there will be some degree of backwards compatibility after upgrades, and that we have a way of adding regression tests in case something does change.
• Clean code: We could treat open-source libraries as black boxes, and refuse to look inside of them, but in my experience, I often find myself digging into the internals of a library to debug something or add a capability, so I want the code to be developed to a high bar of software engineering best practices. Is the code easy to read? Does it have red flags, like commented-out lines of code? Does it have a build system? Does it pass JSHint?

Will it be a good user experience?

If the JS library does not create a UI component, then only the first few of these matter.

• File size: How much will it contribute to your JS download? For context, jQuery gzipped and minified is 18k and Select2 is 7K.
• Performance: Besides size, other aspects of a JS library can affect its performance, like if it does heavy DOM manipulation, graphics rendering, computation, synchronous storage calls, etc.
• Browser support: Check that it supports all your desired browsers. Many libraries these days purposefully don't support older browsers, because they're designed to be lightweight and only for mobile browsers.
• Accessibility: Many libraries for UI components look great, but make no attempts at accessibility. For example, Select2 has known accessibility issues, which many folks don't realize until after they've integrated it and been audited for poor keyboard support. For a quick check, you can run WAVE on the library's demos page.
• Responsive: If your users will ever use the UI component from a library on a mobile browser, then it should work well for them there. Are the buttons big enough? Does it use touch events? Does it scale to small screen sizes?

If all things are roughly equal, I sometimes take the call-a-friend approach: I'll ask colleagues or Twitter folks for their favorite library for the problem. Sometimes everyone answers differently and I'll wish I never asked, but other times there's a common favorite, and that gives me the confidence to go with it.

So, tell me, what am I missing — what do you look for in a library?