How to evaluate a new JavaScript library?

How to evaluate a new JavaScript library?
Average rating: 0
(0 votes)

Thanks! You’ve rated this material!

Here, in the developers community, we often argue which JavaScript library/framework is better. Whether you are the Angular adept or trying to choose between Vue and React, there are always some arguments you follow to support your choice. Which criteria do you follow when choosing new technology or framework? Today Syndicode would like to share with you some great points on how to evaluate a new JavaScript library.

To start with, the next criteria are no means an absolute measure of a library’s worth. This is the checklist you can follow to compare new and old JS libraries to choose what characteristics are  more important for you. Still, every single project has its own requirements and the tech stack defined according to these requirements. Here we go! For each point, choose the result (1, 2 or 3).

How to evaluate a new JavaScript library?

12-point scale that covers the main aspects of picking any technology

  • Features
    What it can do?

    1. Unlocks things that were just not possible before.
    2. Lets you do the same things as before, but in a better way.
    3. Does less than current solutions.
  • Stability
    How often developers run into errors?

    1. Fewer bugs, and issues become easier to debug and solve.
    2. Adopting the technology does not have an impact on your software’s stability.
    3. New bugs and issues arise as a direct consequence of adopting the technology.
  • Performance
    Is it allow you to you save precious milliseconds and improve your webapp’s performance?

    1. Lighter bundle, faster load times, or other performance improvements.
    2. Adopting the technology does not have an impact on your software’s performance.
    3. Adopting the technology slows down your app measurably.
  • Package Ecosystem
    This is a sign that the technology has reached a certain maturity level.

    1. The ecosystem has unambiguous solutions for common concerns; third-party packages are well-maintained and well-documented.
    2. Budding package ecosystem with many competing new options.
    3. No package ecosystem to speak of, lots of manual work required.
  • Community
    Are there a dedicated forum or Slack channel to help when running into issues?

    1. Forum and/or chatroom (Slack/Discord/etc.) with daily activity, GitHub issues addressed within a day. Many answered Stack Overflow questions.
    2. Forum and/or chatroom with infrequent activity.
    3. No community beyond GitHub.
  • Learning Curve
    How easy and fast it is for the new developer to jump into?

    1. Possible to get started in a single day.
    2. About a week required before becoming productive.
    3. More than a week required to learn the basics.
  • Documentation
    How clear the documentation is? Does it cover all the aspects to discover the new technology?

    1. Dedicated documentation site, screencasts, example projects, tutorials, API documentation, and well-commented code.
    2. Basic Read Me and API documentation.
    3. Very succinct Read Me, the only way to know how to use the library is to look at its code.
  • Tooling
    Are you ok with presented extensions, utilities and so on?

    1. Two or more of: browser extensions, text editor extensions, CLI utility, dedicated third-party SaaS services.
    2. One of: browser extensions, text editor extensions, CLI utility, dedicated third-party SaaS services.
    3. No external tooling.
  • Track Record
    For how long it has successfully been working?

    1. Has been around for 4+ years, adopted by major companies and well-known tech consultancies.
    2. Has been around for 1–4 years, used by early adopters and smaller-scale consultancies.
    3. Has been around for less than a year, no real adoption yet.
  • Team
    Of course, lone maintainers can also create major innovations, but are there any huge company behind?

    1. Maintained by a major company with a dedicated open-source team.
    2. Maintained by a medium-sized team of engineers with solid individual track records.
    3. Lone maintainer working independently.
  • Compatibility
    Be aware. A fast improvement rate can also mean frequent breaking changes as new best practices replace old patterns, leaving early adopters to pay the refactoring costs.

    1. Updates are mostly backwards-compatible, deprecations are handled with warnings, and incompatible older versions are maintained for two years or more.
    2. Breaking changes do happen but are well documented and are rolled out gradually.
    3. Frequent breaking updates requiring major refactoring without the proper guidance.
  • Momentum
    With enough momentum (let’s say ‘hype’), a new software project can attract more users and more contributors, which means bugs are found and fixed faster, a package ecosystem can develop, and everybody ultimately ends up better off.

    1. Hype Level – Top of Hacker News, thousands of GitHub stars, talks at major conferences.
    2. Some interest around the initial launch, hundreds of GitHub stars.
    3. Lone developer toiling away in obscurity.

This will help you rate your chosen library!

Thanks to Sacha Greif for these awesome tips! You can find also other approaches on how to evaluate JS libraries in the author’s original article.

p.s. If you wonder how many libraries there are in JavaScript, some sort of information could be found here.

If you have any questions, contact us! We’ll solve your puzzle and take the advantage of the best technologies to complete your project!

Rate this article, if you like it

Thanks! You’ve rated this material!

Got a project? Let's discuss it!

*By submitting this form you agree with our Privacy Policy.

Mailing & Legal Address

Syndicode Inc. 340 S Lemon Ave #3299, Walnut CA, 91789, USA

Visiting & Headquarters address
Kyiv Sofiivska 1/2a, 01001, Kyiv, Ukraine
Dnipro Hlinky 2, of. 1003, 49000, Dnipro, Ukraine
Email info@syndicode.com
Phone (+1) 9035021111