JavaScript development is like assembling 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 an approach to development and encourages structuring applications around small and reusable modules.
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.
Factors to consider when picking a JavaScript library for your React Native app
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 won't 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. The overall size of the JavaScript code is an important factor.
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, the default React Native bundler, Metro, doesn’t support tree shaking currently. 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.
What’s worth pointing out is that it’s not the case with the Hermes engine, which automatically pages only necessary <rte-code>bytecode<rte-code> into memory.
How to analyze bundle size
Keeping tabs on your bundle size is very important. We can make use of the react-native-bundle-visualizer to analyze the bundle with the help of GUI. We can get the details of any added library in the bundle; hence deciding if it’s worth keeping or removing that library. This package produces output using the app bundle in the following form:
Be more selective and use smaller specialized libraries
The easiest way to overcome this issue is to employ the right strategy for architecting the project upfront. 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 dates. Let’s imagine you are about to calculate the elapsed time. Rather than pulling down the entire <rte-code>moment.js<rte-code> library (67.9 Kb) to parse the date itself:
you can use <rte-code>day.js<rte-code> (only 2Kb) which is substantially smaller and offers only the functionality you need.
If there are no alternatives, the rule of thumb is to check if you can import a smaller part of the library. For instance, many libraries such as <rte-code>lodash<rte-code> have already split themselves into smaller utility sets and support environments where dead code elimination is unavailable.
Let’s say you want to use <rte-code>lodash<rte-code> map. Instead of importing the whole library, as presented here:
you could import only a single package:
As a result, you can benefit from the utilities that are a part of the <rte-code>lodash<rte-code> package without pulling them all into the application bundle.
If you’d like to have constant insight into your dependencies' size impact, we highly recommend the import-cost VSCode extension. Or using the Bundlephobia website.
Faster loading means better business results
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.
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.
Are you struggling with choosing the right toolset for your project? Trust our React Native development company to match the technology with your business objectives.
