How to Pick The Right External JavaScript Libraries for Your React Native App

Mike Grabowski

blog content

Need help with React Native?
hire us
Our React Native EU Conference is back
register nowlearn more

How can working with the right JavaScript libraries help you boost the speed and performance of your apps?


This article is an excerpt from The Ultimate Guide to React Native Optimization. In this part, we focus on the dos and don’ts of choosing external libraries for your next React Native project.

Why is it important?

External libraries might be one of the most important factors affecting the size and speed of your React Native app. That's why you should be extremely careful when selecting the one you will use for your project. Here, you will learn how to find the library that has all the desired functionalities but at the same time does not degrade the performance of your app.

In the previous parts of our guide, we have discussed:

Be sure to check them out. Now let’s get back to external JavaScript libraries.

Think twice before you pick your external library

Issue: You are choosing the libraries without checking what is inside.

JavaScript development is like assembling the applications out of smaller blocks. To a certain degree, it is very similar to building React Native apps. Instead of creating React components from scratch, you are on the hunt for the JavaScript libraries that will help you achieve what you had in mind. The JavaScript ecosystem promotes such approach to development and encourages structuring applications around small and reusable modules.

list of external JavaScript libraries for React Native

This type of ecosystem has many advantages, but also some serious drawbacks. One of them is that developers can find it hard to choose from multiple libraries supporting the same use case.

When picking the one to use in the next project, they often research the indicators that tell them if the library is healthy and well maintained, such as the Github stars, the number of issues, contributors, and PRs.

What they tend to overlook is the library’s size, number of supported features, and external dependencies. They assume that since React Native is all about JavaScript and embracing the existing toolchain, they will work with the same constraints and best practices they know from making web applications.

Truth is – they will not, as mobile development is fundamentally different and has its own set of rules. For example, while the size of assets is crucial in the case of web applications, it is not equally important in React Native, where assets are located in the filesystem.

The key difference lies in the performance of the mobile devices and the tooling used for bundling and compiling the application.

Although you will not be able to do much about the device limitations, you can control your JavaScript code. In general, less code means faster opening time. And one of the most important factors affecting the overall size of your code is libraries.

Complex libraries hamper the speed of your apps

Unlike a fully native application, a React Native app contains a JavaScript bundle that needs to be loaded into memory. Then it is parsed and executed by the JavaScript VM.

build and run time

While that happens, the application remains in the loading state. We often describe this process as TTI – time to interactive. It is a time expressed in (well, hopefully) milliseconds between when the icon gets selected from the application drawer and when it becomes fully interactive.

Unfortunately, Metro – the default React Native bundler – doesn’t support tree shaking as of now. If you’re not familiar with this notion, read this.

It means that all the code that you pull from npm and import to your project will be present in your production bundle, loaded into the memory and parsed.

That can have a negative impact on the total startup time of your application. The easiest way to overcome this issue is to employ the right strategy for architecturing the project upfront.

Solution: Be more selective and use smaller, specialized libraries

If you are about to pull a complex library, check if there are smaller alternatives that have the functionality you’re looking for.

Here’s an example: One of the most common operations is manipulating the dates. Let’s imagine you are about to calculate the elapsed time. Rather than pulling down the entire moment.js library (67.9 Kb) to parse the date itself:

Parsing date with moment.js

You can use day.js (only 2Kb) which is substantially smaller and offers only the functionality you were seeking.

Parsing date with day.js

If there are no alternatives, the good rule of thumb is to check if you can import a smaller part of the library.

For instance, many libraries such as lodash have already split themselves into smaller utility sets and support environments where dead code elimination is unavailable.

Let’s say you want to use lodash map. Instead of importing the whole library, as presented here:

Using lodash map by importing the whole library

You could import only a single package:

Using lodash map by importing only a single function

As a result, you can benefit from the utilities that are a part of the lodash package without pulling them all into the application bundle.

Benefits: Your app loads faster and that makes all the difference

Mobile is an extremely competitive environment, with lots of applications designed to serve similar purposes and fighting over the same customers. Faster startup time, smoother interactions and overall look and feel might be your only way to stand out from the crowd.

According to Akamai’s report on the online retail performance, just one-second delay in mobile load times can cut the conversion rates by up to 20%.

That’s why you shouldn’t downplay the importance of choosing the right set of libraries.

Being more selective with third-party dependencies may seem irrelevant at first. But all the saved milliseconds will add up to significant gains over time.


JavaScript ecosystem provides you with a vast array of libraries, but not all of them will be equally good in fulfilling your needs. As they impact the size of your code, always choose smaller and specialized libraries over the complex ones. If that’s not an option  –  try to import only the parts of the library you’re interested in.

This approach will help you not only boost the speed and performance of your app. It will also translate into seamless user experience and better business results.

Note: Read this article by Google to learn more on how speedy apps can drive your growth: Milliseconds earn millions: Why mobile speed can slow or grow your business.

In the next part of our guide, we tackle the issues you may face when using libraries that are not optimized for mobile.


We are the official Facebook partners on React Native. We’ve been working on React Native projects for over 5 years, delivering high-quality solutions for our clients and contributing greatly to the React Native ecosystem. Our Open Source projects help thousands of developers to cope with their challenges and make their work easier every day.

Contact us if you need help with cross-platform development or React Native development. We will be happy to provide a free consultation.

Mike Grabowski
Co-founder & CTO of Callstack. Mike is a React Native core contributor and author of many libraries. When he isn't working, he is on a race track.
arrow icon
MORE posts from this author

learn more

More posts from this category

stay tuned

Subscribe to our newsletter

You may unsubscribe from these communications at any time. For details see the Privacy Policy.