Choose a JavaScript library or framework
This article shares insights on how you might pick a library or framework to use within your web application. The discussions herein will help you to weigh the pros and cons in finding the JavaScript library or framework that is right for the business problem you're trying to solve. Understanding which pros and which cons apply in different situations is key to vetting the large number of JavaScript library choices that are available.
What are JavaScript libraries and frameworks #
What is a JavaScript library? In its simplest form, a JavaScript library is prewritten code that you can call in your project's code to achieve a specific task.
This post mainly mentions "libraries". However, many of the discussions are also applicable to frameworks. Basically, the difference between the two can be summarized as follows:
- For a library, your application code calls the library code.
- For a framework, your application code is called by the framework.
The following practical examples help to illustrate the differences.
Example call to a JavaScript library #
A JavaScript library performs a specific task and then returns control to your application. When you use a library, you control the application flow and choose when to call the library.
In the following example, application code imports a method from the lodash library. After the function completes, control is returned to your application.
import capitalize from 'lodash.capitalize';
capitalize('hello'); // HelloWhen the lodash.capitalize method is executed, it calls pre-written JavaScript code that capitalizes the first character of a string.
Example use of a JavaScript Framework #
A JavaScript framework is a predefined code template within which you construct your application's behavior. That is, when you use a framework, the framework controls the application flow. To use a framework, you write your custom application code, and then the framework calls your application code.
The following example shows a code snippet that uses the Preact JavaScript framework:
import { createElement } from 'preact';
export default function App() {
return (
<p class="big">Hello World!</p>
)
}In the example, notice that the framework has a lot more control over the code you write, and in some cases, the framework even takes control over when to execute your code.
Why use a library? #
Using a JavaScript library can help to avoid unnecessary code repetition. Libraries can abstract away complex logic, such as date manipulation or financial calculations. A library can also help get your initial product out, rather than having to write all the code from scratch, which can take time.
Some client-side JavaScript libraries help abstract away quirks of the web platform. A library can also serve as a learning tool. For example, if you're unfamiliar with animation easing functions, the source code of a library can teach you how such easings work.
Some libraries are backed by large companies that invest time and money into keeping libraries up to date and secure. Many libraries are accompanied by extensive documentation, which offers you and your team a quick way to familiarize yourself with the library's usage.
Ultimately, using a JavaScript library saves you time.
Why should you care about library usage? #
Technically, you can develop your web application from scratch, but why go to the trouble when you can use free (open source) software, or purchase a solution that, in the long run, can save time and money? There are a large number of JavaScript libraries and frameworks available, each offering a unique approach to solving problems, and each having different characteristics. For example:
- A library can be written and maintained internally rather than by a third party.
- A library can have specific legal licenses that make it suitable or unsuitable for your web application.
- A library can be outdated or unmaintained.
- A library can simplify a set of complex tasks and save you a lot of time and money.
- A library can be widely used in the community, and can be well known amongst developers.
As you might suspect, different characteristics can affect your web application in different ways. Sometimes, the decision is just not that deep, and you can safely swap out a library if you don't like it. However, sometimes a library can have a significant effect on your work and your web application, which suggests a more informed approach could be necessary.
There are some non client-side JavaScript environments, such as on the server (run in a cloud environment) or on a Raspberry Pi, where you may need to adjust the criteria you use to vet libraries and frameworks.
Performance #
The performance effect of a JavaScript library on a client-side web application should not be ignored. A large JavaScript library can disrupt the loading performance of your page; remember, milliseconds make millions.
Consider a scenario where you use a JavaScript library for animation. Some libraries can easily add tens of kilobytes, and in some cases, even hundreds of kilobytes. JavaScript resources like this can add a significant delay to your page load as the browser needs to download, parse, compile and execute the code.
The bigger the JavaScript library, the bigger the performance effect on your users.
When evaluating or using a JavaScript library or framework, consider the following suggestions to improve performance:
- Given a large JavaScript library, consider using a smaller alternative. For example, date-fns offers a lot of functionality at a more reasonable size than some other options.
- Following on from the previous date-fns example, import only the functions that you need, such as:
import { format } from 'date-fns'. Be sure to combine this approach with tree shaking, so that a minimal JavaScript payload is built and sent to your users. - Use performance testing tools such as Lighthouse to observe the performance effect of using a certain JavaScript library. If a library adds a one-second delay to your page load time (don't forget to throttle your network and CPU during testing), then you may need to reevaluate your library of choice. In addition to checking page load, be sure to profile any web page behavior that invokes code from the library in question—page load performance does not tell the full story.
- If comments are welcomed by the library author, then submit your performance observations, suggestions, and even contributions to the project. This is where the open source community shines! If you decide to make a contribution, then you may need to check with your employer first.
- Use an automated bundle tracking tool, such as bundlesize, to watch for unexpectedly large updates to a library. It's common that a JavaScript library will grow over time. Feature additions, bug fixes, edge cases, and others, can all add to the file size of a library. Once you/your team have agreed to use a library, updating the library may be less of an issue and could raise little-to-no questions. This is where it's helpful to rely on automation.
- Look at your requirements for a library and evaluate whether or not the web platform offers the same functionality natively. For example, the web platform already offers a color picker, which removes the need to use a third-party JavaScript library to implement the same functionality.
Security #
Using a third-party module carries some inherent security risks. A malicious package within your web application codebase can compromise the security of both your development team and your users.
Consider a library published to the NPM ecosystem. Such a package may be legitimate. However, over time, the package can be compromised.
Here are some security tips to consider when using or evaluating third-party code:
- If you use GitHub, then consider the code's security offerings, such as Dependabot. Or, consider alternative services that scan for vulnerabilities in your code, such as snyk.io.
- Consider using code-auditing services, a team of engineers who can manually audit the third-party code you're using.
- Evaluate whether you should lock your dependencies to a specific version, or commit your third-party code within your version control. This can help lock your dependency to one particular version—that is presumably deemed safe. Ironically, this can have a counter-effect within security, as you may miss out on vital updates to the library.
- Scan the project home page, or GitHub page, if one exists. Research whether outstanding security issues exist, and whether previous security issues were resolved within a reasonable timeframe.
- Third-party code that uses other third-party code can carry more risk than a library that has zero dependencies. Be mindful of this risk.
Accessibility #
You may be wondering how software libraries are related to web accessibility. While a software library can be used in different environments, in the context of a client-side JavaScript-based library, web accessibility is of high importance.
A client-side JavaScript-based library (or framework, for that matter) can increase or decrease the accessibility of your website. Consider a third-party JavaScript library that adds an image slider to a page. If the image slider does not account for web accessibility, you as the web developer may overlook such an important feature, and release a product that misses critical features, such as the slider being keyboard navigable!