Using a JavaScript library versus building the functionality yourself

Libraries save time by letting developers reuse existing work done by others. Especially for languages like JavaScript, that come with a small standard library, external libraries are essential for building for large applications.

However there are some downsides as well, like unnecessary code and less control over the behavior of the third-party component.

This post will list the pros and cons of using a library instead of creating a custom solution.

Pros

Saving effort

This is the big one. Building functionality takes time, so if someone else already built it just re-using the code makes perfect sense.

Say you need a color picker for your app. You could spend 2 weeks building a custom tool, or you could spend an hour finding a library and learning how to use it. If the color picker isn't absolutely core to the experience of your app then you'll be way better of using an existing one.

Increasing quality

Not only will using a library be quicker than building it yourself, the end result will probably also be higher quality. The combined efforts of many people exceed the resources available in most cost-conscious companies.

People will already have found and fixed iOS-specific bugs, or discovered a UX problem. If you write the code yourself all the QA work is left for your team to do.

New team members may already be familiar with the library

If you use a popular library like Lodash or Redux your new team members may already have used it at a previous job and know the library API and best practices for using it.

When you move to a new project or company you can take your library knowledge with you and be more efficient from the get-go.

Better documentation

Unlike internal modules libraries are usually well documented (or at least have some documentation!). You can search through issues people had with the library in the past and find answers on StackOverflow.

Cons

Libraries may be hard to customize and debug

The library you're considering may only be 90% the way you want it and require several tweaks before you can use it. To adjust the library you need to understand the source code, including all the complexity the library was written to handle - even though the complexity wouldn't be needed just for your app!

Reading the code, understanding the build system, and making the adjustments takes a lot of effort! Sometimes writing just the code you need for your use case can be more effective.

Similarly, if you find a bug introduced by a third-party library tracking it down and fixing it can be difficult.

Download size

If you're writing front-end code every user will have to download the libraries used by your page. Since libraries are meant to be used in a wide variety of projects they will contain a lot of functionality and options that you don't actually need.

However some libraries allow you to limit what you include in your bundle to just what you need. For example, if you write import { filter } from "lodash" instead of import _ from "lodash" then tree shaking at build time removes all code that's not necessary.

Sometimes you can get the work done by just copying a few lines from Stack Overflow and putting it in a utils.js file.

Abstraction mismatch

Sometimes libraries can force you to solve a problem in a specific way, which may not be the most obvious for your use case. In that case it can be useful to wrap the library usage and provide a more useful API that's optimized for your needs to the rest of the application.

This especially applies if you are trying to standardize a bunch of existing solutions across your codebase. Building your own interface can make this a lot simpler.

Licensing issues

While open-source libraries are usually fine to use just because you can download the library for free doesn't mean you can use it commercially.

If you pay for a library there might still be restrictions, for example on how many different domains you can use it.

This might not be a decision you can make directly in the development team and can take a manager's time.

Security

When using external code there's a chance the dependency has security problems. Or a dependency of the dependency has security problems. Or that a version update introduces a security problem.

You can carefully review the library code, or use only libraries by large reliable vendors.

However, you have the greatest control when writing the code yourself. Of course you'll still have to write secure code, but at least the risk of having code that's intended to be insecure is greatly reduced.

Summary

Using lots of libraries is the norm for JavaScript projects. This saves time and creates a shared standard between projects.

When making a decision here are a few questions to consider:

  • How important is this functionality for your application?
  • How close is the library to what you need?
  • How accessible is the source code if you ever need to modify it?
  • Is the library well tested?
  • What libraries does your team have experience with?
  • How large are the resources of your project?