- ReactJS for reactive UI frontend
- VueJS for reactive UI frontend
- Svelte for reactive UI frontend
- Axios for HTTP request
- Puppeteer for controlling high-level API of Chrome or Chromium
- Prisma for ORM (Object-Relational Mapping) database that type safe
- Node-Redis for Redis client
Here the example I want to find the date picker for react in yarn package manager it showing 1000+:
Then my questions is:
- Is the first result always the right one?
- Does it really help my development?
- Is it easy to use?
In this article, I'll share my experience on what to do to answer those questions.
That's why it forces me to keep up-to-date with the library and I don’t like doing it anymore.
I try to figure out if I can find another way more easily and I enjoy doing it.
Here the tips:
Tips #1: Focus on what you expert at it
It is better to choose the library you already know well rather than the library you are new to.
Choosing the new library always lead to adding some extra effort to understanding all of the usage. If you are already familiar with a library that has the same functionality, it is better to choose that one. It doesn't matter if the library is old, as long as you know how to use it well, it will still save you time. Never bet on trying new libraries if you want to focus on solving the real problem.
Focusing on solving the real problem will increase your development speed.
Tips #2: Check the documentation first
Looking at the documentation first can help you make a quicker decision about which one to choose.
Understanding the format of the documentation.
The documentation is usually written in a format that can be easily understood and used to explain the functions and options. Every library's documentation is written in a different format, so a quick way to check the documentation is to understand the format first. Once you're familiar with the documentation format, you will be able to easily understand all of the library features.
A library with clear and easy-to-understand documentation is a good sign that you have chosen the right library.
The documentation reference
The documentation reference is a resource that explains the details of the functions and options of the library, including what syntax, parameters, and data type to use. Understanding the reference helps us quickly adapt to using the library. This point can be optional when you are using extensions like Intelligent code completion in your IDE it will automatically show you the reference while you code.
This is an example of code reference showing in an IDE. I am using VS code and typescript with the built-in Intelligent code completion. When I call the getFirestore function from the Firestore library, it shows the description, parameters, and event examples.
The code examples
This is my favorite thing in the documentation because it can speed up understanding the usage of the library. In my experience, checking the example is the fastest way to find out what I'm looking for. Unfortunately, not all of the documentation in the library has code examples.
The code example in the documentation helps us to understand the library more quickly and easily.
Here's an example of a documentation that has code examples:
Firestore provides a code example of how to add data.
The good documentation provides information that makes it easy to use the library. The written format is easy to follow, the code reference is easy to find, and there are examples of code usage.
Tips #3: Don't bet on low-maintained open source libraries
You should never using low maintained library in your project.
Choosing the low-maintenance open source library, you may have to deal with many unresolved issues and uncovered bugs. I've encountered this before when I chose a low-maintenance library - I got a bug. I tried finding a solution on the internet but no one was discussing it. At the end, I have two options: fix the bug myself or change the library. If I choose a good maintenance library, those efforts should never have happened.
The lower the maintenance on a library, the greater the likelihood you will be stuck on problems.
There are three criteria I use to determine whether a library has a good maintenance track record:
- Check the last commit in the master or main branch. Make sure it is not more than 3 months ago.
- Check the open issues in the repository, make sure there is someone who will respond to it within 3-7 days after the issue is opened.
- At least have dozens of forks on GitHub.
The good open source library is maintained by active contributors.
Tips #4: Avoid changing existing libraries
There's no need to change the library unless you're stuck on a problem with it, or you'll be overwhelmed with unnecessary work.
- There are no security issues in the existing library.
- The existing library is not deprecated yet.
- There are no recurring problems in the existing library.
As long as your existing library meets the checklist, you should not change it. Save your time and focus on solving the most valuable problems.
Tips #5: Maybe you don’t need the library at all
- Choose the library you are most familiar with.
- Check the documentation first to make sure it is easy for you to understand.
- Avoid using libraries that aren't well maintained.
- Do not change the existing library.
At the end, users don't care about the libraries you use, but too much use of libraries can make your app run slowly and give users a bad experience.