While breaking the entire project into smaller tasks or components, we often end up finding patterns that seem to be common problems to have been solved by many developers beforehand.
The basic idea while developing a piece of code is to not spend time on things that are just about reinventing the wheel and to reuse parts wherever possible, and this is where frameworks and libraries come into the picture.
Libraries are like the refined packaged solution to those common problems which have been worked upon by many developers and hence provide us with a ready-to-use piece of code, making the development cycle a bit easier.
Though all of this looks very beautiful to think about, the sheer abundance of so many options to choose from leads the developers into another web of confusion.
This is exactly what we would try to make simpler today! Through this article, I would try to lay out a process and factors to consider for choosing a library.
It is important to have a clear understanding of the problem you are trying to solve. For example:
- If your need is to have a collapsible list, you would just want to include an accordion component library in your project instead of a library that has a pool of other components too.
- If your need is to have multiple (from the atomic level to hybrid level) ready-to-use components and make the development faster, you would probably go for a library that has a pool of components instead of selecting a separate library on a component-to-component basis.
- What kind of functionality/behavior should that component have in place and how much customization are you able to observe in the library. Does it provide ease to make those customizations exclusively instead of you making efforts and changes in its codebase?
When you have these requirements and understanding in place, figure out 3–4 libraries that you feel would suit your use case best, and then we can select the best fit out on the basis of the factors discussed. You can just search for your requirement in the npm directory to get a list of libraries.
After sorting down to 3 – 4 libraries, I finalize upon a library by considering the following factors:
- Bundle size: Size that the package brings with it to the project.
- Accessibility: A11y principles followed by the library.
- Cross-browser compatibility: Browser support that the library provides.
- Customizable/Flexibility: Ease to customize the component.
- Community: Popularity of the library (Usage and maintenance).
- Free for commercial use/License: License under which the library is released.
- Security vulnerability: Potential security risks that the library might bring with it to your project.
Now let’s try to understand one by one in detail why these factors are important and how to compare.
- Bundle Size: 📦
- The idea behind bundling is to group multiple files or modules into a single file or module. Therefore, it helps in reducing the number of individual HTTP requests to the server for fetching the files.
- Bundlers also come in handy to reduce the total file size by performing optimizations- identifying unused code, identifying dependency relations to make fetching easier, and many such optimizations to basically have an efficient file being served to the browser.
- So while choosing any library, we should take into consideration the size that the package brings with it to your project. There are two ways to look at it:
→ Unpacked size: This is basically the unzipped size of the package. You can have this data from npm documentation of the library.
→ Minified bundle size: This is a more optimized size that the package would include in the project. Utilities such as bundlephobia do a good job to get this metric. It also helps in identifying if the package supports tree shaking or not. (Bundlephobia is preferred for frontend packages and packagephobia for backend packages)
2. Accessibility: ♿
As the name suggests, accessibility is about making your web pages accessible to as many people as possible.
Think of accessibility as treating everyone the same, and giving them equal opportunities, no matter what their ability or circumstances. Just as it is wrong to exclude someone from a physical building because they are in a wheelchair (modern public buildings generally have wheelchair ramps or elevators), it is also not right to exclude someone from a website because they have a visual impairment. — MDN docs
Accessibility is also enforced by the law in some countries, and hence not wanting to lose customers would also mean you follow the best practices while developing your product. In my opinion, it should not be considered as an afterthought but should be considered an equally important part of your development cycle.
Making your website accessible would potentially involve: Use of semantic HTML for creating components, the right use of aria tags, having proper contrast of color, adding keyboard event listeners, adding alt texts, and proper roles so that the accessibility tree that the browser produces covers everything that is visually present to be conveyed in the best way possible by the screen readers too.
And hence, while considering any library you must keep this factor in mind. Most of the libraries in the npm documentation either specify this separately as to which accessibility guidelines it adheres to or have the accessible tests in their storybook component demo or would provide with just the demo of the library. If it is just a demo, you can check out the accessibility tree for that component using the developer tools and choose for yourself which library takes care of it best.
3. Cross-browser compatibility 🌐
A good website is one that works the same way across all the browsers and in case if some browser lacks some feature, it should handle such scenarios properly.
This is what cross-browser compatibility talks about and hence should be considered while choosing a library so that you don’t have to code and handle such scenarios by yourself.
You’ll find this info in the npm documentation itself in most of the scenarios.
4. Security vulnerability 🛡️
Along with all the good parts, open-source code might come with some security vulnerabilities that might get exploited and can cost your product/company, it might get vulnerable to some malware injections, data breaches, or DDOS attacks.
So this is one concern that you must keep in mind and check thoroughly while finalizing your library. This is where vulnerability scanner utilities can help you. You can use scanners such as synkAdvisor to see the security issues with any packages and it also tells how healthy a package is taking into consideration security and few other factors that we discussed.
5. Customisable/Flexibility ⚙️
While you do sort these 3–4 libraries based on your requirements, the exact match is hard to find. A component that would follow the same color theme, same functionality/behavior, and same styling to the component and its content would probably never be the case.
So in order to align the chosen component with the exact requirement, what eases the development is the flexibility that the component provides with respect to customizations.
So while you finalize a component, do have a look if the component provides that ease for customizations, does it provide props to achieve those customizations or not.
6. Free for Commercial use/license 🆓
An open-source license tells you what you can and can’t do with the open-source code. Consuming the library for your company’s project would mean that you will be consuming it for profitable use cases and you would not want to get into any compliance requirements or legal concerns around the consumption.
So it is good to have an idea about the types of open-source licenses there are and which one you would want to choose. You can get to know about the license under which a particular library is released via the npm documentation.
MIT License is by far the most popular open-source license and it comes with zero concerns around any legal aspects, making profit out of the library or open source your usage code.
7. Community 👩🏼💻
One of the most important factors that are easily visible and very convincing while selecting a library is the consumption of that library by the developers. How actively is the community using it and how actively are developers contributing to it and maintaining it!
You can consider this factor by comparing the weekly downloads from the npm documentation. Another way is to compare the stats from GitHub repos of the packages, by seeing the stars on the repo or the ‘used by’ section to see how many projects are dependent on it.
For more detailed and well-documented data around this, you can also check the utilities such as synkAdvisor, which beautifully represents everything that’s stated above plus maintenance graphs and stats around it.
This seems to be like a long process to follow up on, but trust me it would save your time from just mindlessly looking for different libraries and building out perceptions rather than factual comparisons. Once you have gone through each of these factors, you would have a clear idea around which library aligns with your needs best, and boom — You have your library 📦 selected!
Thanks to Vedang Manerikar and Nachiket Kakatkar!