What do you need to bring to the attention when choosing new libraries for development? The Geniusee team analyzed and selected 10 criteria for evaluating any technology.
10 criteria How to choose JS library.
The first criterion for choosing this or that technology is its special features. But the main thing here is how far you go in pursuit of them. For example, React is the most popular library today, but with a big minus: it is not enough for full work. Routing and state management require third-party libraries - React-Router and Redux.
This is where Vue, the main competitor to React, comes onto the scene. For these use cases, it provides a batch solution. But if you get too carried away with it, you get a bloated complex structure that tries to be everything at the same time.
Therefore, sometimes the best way out is minimalism. The Lodash or Ramda libraries allow you to replace messy nested loops with concise functional expressions, and this makes them invaluable tools.
However, the bottom line is to find a balance.
- It reveals things that were previously impossible
- It allows you to do the same as before, but better
- It does less than the solution you are currently using
You may have the most elegant full-featured structure, but it's useless if developers run into errors every two minutes.
In the area of data loading, the GraphQL type system helps sites run smoothly.
- Fewer errors, easier to debug and solve
- Technology does not affect software stability
- New errors and problems arise as a direct consequence of the introduction of technology
If you studied martial arts, then you know that speed is important, not strength. Similarly with the site: if it takes 15 seconds to load, the user will close the tab, and you will lose the battle before it starts.
- The solution is easier and faster than that you are using now, faster boot times or other performance improvements
- Technology does not affect software performance
- The introduction of technology significantly slows down the application
Before exploring new technology, it is important to take a look at the ecosystem that has developed around it.
Firstly, it saves time, because it allows you to use someone else's work, and not do everything yourself. The presence of an ecosystem shows a certain level of technology maturity. Therefore, supported third-party libraries are one of the best signs that developers have been using it for a long time.
- It has unambiguous solutions to common problems. Third-party packages are well maintained and well documented
- There are many new options that competing with each other
- We are not talking about a package ecosystem; a lot of manual tuning is required
Another important factor is the active community. A separate forum or channel in Slack is very helpful in solving problems. The well-maintained page on GitHub is a must.
- A forum and/or chat (Slack/Discord/other) with daily activity, questions from GitHub are considered during the day
- Forum and/or chat with rare activity
- There is no community outside of GitHub
A smooth learning curve increases the likelihood that developers will adopt new frameworks or libraries. It is a mistake to believe that for the sake of technology, people are ready to overcome any obstacle to its mastering, no matter how cool it may be.
Meteor was very easy to use when it first appeared - but it demanded that you immediately apply its entire stack, which is very difficult to implement for existing projects.
Learning Curve Assessment:
- You can start work in one day
- About a week is required to delve into the work
- It takes more than a week to learn the basics
Most of the technology with a smooth learning curve has excellent documentation. It isn’t easy to achieve: it is written by professionals who are far from the new experience of developers.
Therefore, to write good documentation, you need to forget for a while what you know and put yourself in the place of the discoverer of technology.
It also requires anticipation of common problems, understanding of user behavior and, above all, maintaining relevance, because the source code is changing. And all this takes up valuable time from actual programming.
Given all these factors, you understand why good documentation is a rare and valuable thing!
- A separate site with documentation, screencasts, sample projects, tutorials, API documentation, and well-commented code
- There are only the basics and API documentation
- Concise documentation. The only way to find out how to use the library is to look at its code
Like the documentation, some additional tools may seem like a minor detail, but in fact, they are vital to the popularity and success of any technology.
One of the main reasons for the success of Redux is its amazing extension for the DevTools browser, which allows you to visualize Redux storage and actions in a very user-friendly way. Exactly the same way, the excellent TypeScript VS Code support worked wonders for its adoption.
- Two or more: browser extension, text editor extension, CLI utility, special third-party SaaS services
- One of the tools: browser extension, text editor extension, CLI utility, special third-party SaaS services
- No external equipment
Even the most elegant, well-documented libraries will be discarded if they live only six months.
Track Record Assessment:
- Works for 4 years, used by large companies and renowned technical consultants
- Age 1 to 4 years old, used by early adopters of technology and smaller consultants
- Released less than a year ago, there is no real adoption yet
The great thing about using advanced libraries is that they are developing pretty fast. But this can be a serious drawback.
Fast improvement speeds can cause frequent crashes, as new methods replace old templates, forcing first users to pay for refactoring.
React Router created a lot of problems when they decided to completely change their API between versions 3 and 4, as well as Angular when they switched from Angular.js to the new “just Angular”.
Frequent updates attract when you are just starting a new project. But if the web application has been working for a long time, then the last thing you need is to spend several weeks refactoring and tuning every time a new version of the library is released.
- Updates are backward compatible, and obsolescence is handled with warnings. Incompatible older versions are supported for two years or more
- Failures occur, but are well documented and are gradually resolved
- Frequent updates requiring significant refactoring without proper guidance
Geniusee team wishes you a successful selection and implementation of new technologies!