Umar Hansa on web.dev

Choose a JavaScript library or framework

2022-05-23T00:00:00Z

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'); // Hello

When 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!

Does the responsive typography plugin support users who zoom in or out of the page?
Does the file uploader plugin support file uploads from assistive devices?
Does the animation library offer support for users who prefer reduced motion?
Does the interactive maps plugin support keyboard-only usage?
Does the audio player library offer an appropriate experience on screen readers?

It's reasonable to expect that some level of involvement is needed from you, the web developer, to meet such accessibility requirements. For example:

For any missing features, you can implement such features within your codebase, even while continuing to use the library in question.
With the support of your employer, you can contribute such a missing feature to the library, if the library author allows for such a contribution.
You can open up a dialogue with the library author. For example, are these specific accessibility features on your roadmap? Do you agree they belong in the library?
For popular use cases, you can explore alternative library options that are more accessible; they may exist but are harder to find.
In the extreme case, you may need to ditch a library entirely and implement your features from scratch. This can happen when a library or framework has a degraded accessibility experience on initial use, and you need to undo a lot of what the library or framework is supposedly giving you for free.

Conventions #

A software library that uses established coding conventions is easier to work with. If a library uses a coding convention that is unheard of, then it may be difficult for you and your team to work with such a library.

If a library does not follow common coding conventions (for example, a common style guide), there is not much you can do as an immediate fix. However, there are still a few options:

Be sure to differentiate between the library source code and the API exposed to you, the library user. While the internal source code may use unfamiliar conventions, if the API (the part of the library you interact with) uses familiar conventions, then there may be nothing to worry about.
If the library API does not follow common coding conventions, you can use a JavaScript design pattern, like the proxy pattern, to wrap and contain all interactions with the library to a single file in the codebase. Your proxy can then offer a more intuitive API to other parts of the code within your codebase.

Conventions play a big role with ease of use. A library that includes an intuitive API can save many hours', or even days' worth of people hours, when compared with a counter-intuitive API that needs a lot of experimentation to figure out.

Updates #

As an example, for a fully working library that performs a few mathematical calculations, such a library may rarely need updates. In fact, a feature-complete library is a rare find in the ever-changing world of web development! However, there are times where you want the library author to be responsive and willing to make updates. New research and findings can reveal better ways of doing things, so the techniques used in libraries and frameworks are always subject to change.

When you pick a library or framework, pay attention to how updates are handled, and be aware that such decisions can affect you:

Does the library have a sensible release schedule? For example, updates to the source code repository may happen frequently, but if such updates are not "published" or "released" accordingly, you'll find it can be a struggle to download such updates.
Does the library release updates with a sensible software versioning scheme? A library should save you time. If you have to unexpectedly change your code every time you update the library version, this may defeat the purpose of using that library in the first place. Breaking changes are sometimes unavoidable, but in an ideal world, changes are infrequent and not forced upon library consumers.
Does the library invest effort towards backward compatibility? Sometimes, software updates can come with breaking changes, but also provide a layer of backward compatibility. This allows the library consumer to use the latest library version with minimal changes to their code.

Licensing #

Software licensing is an important aspect of using third-party software libraries. A library author may assign a license to their library. If you are considering using the library, then their choice of license may affect you.

For example, a JavaScript library may have a software license that permits you to use it in a non-commercial environment. For a personal hobby project, this could be a great choice. If your project has a commercial element, then you may need to consider an enterprise license.

When in doubt, consider seeking professional legal advice or defer to the legal team within your company.

Community #

A library or framework that has a large community of users/contributors can be beneficial, but this isn't a guarantee. In general, the more users a library or framework has, the more likely it is to benefit. Consider the following pros and cons to participation in a development community:

Pros:

A large user base could mean a greater chance of bugs being caught early and often.
A large active community could mean more tutorials, guides, videos, and even courses, on the library or framework in question.
A large active community could mean more support on forums and question and answer websites, increasing the likelihood that support questions are answered.
An engaged community can mean more external contributors to the library or framework. They can help deliver features that are otherwise not on the author's roadmap.
When a library or framework is popular within a community, there's an increased likelihood that your peers and colleagues will have heard of, or even be familiar with, such a library or framework.

Cons:

A project with a large and diverse user base can become bloated from constant feature additions. Bloated libraries can harm web performance.
A project with an active and engaged community can be stressful for the authors and maintainers, and may require heavy community moderation.
A project that grows rapidly, but does not have the appropriate support in place, can begin to exhibit signs of having a toxic community. As an example, beginner or junior web developers can be made to feel unwelcome in a certain community due to gatekeeping.

Documentation #

No matter how simple or complex a JavaScript library or framework might be, software documentation can always help. Even very experienced developers use documentation, rather than figuring out the code themselves. Documentation clarifies the API you should use, and how you should use it.

Documentation can even provide sample code, making it easier for you to get started quickly. When you evaluate a library or framework, you can ask some of these questions:

Does the library include documentation? If it does not, you'll need to be comfortable with figuring things out on your own.
Is the documentation clear, easy to understand, and free of ambiguity? Many developers spend large amounts of time on documentation. It may seem small, but clarity within textual documentation can have a big effect on your productivity.
Is the documentation completely automatically generated? Such documentation can be harder to digest and does not always provide clear guidance on how to use an API.
Is the documentation up to date? Documentation maintenance is sometimes treated as an afterthought. If the library is updated but the documentation is not, this can lead to wasted development time.
Is the documentation comprehensive and available in multiple formats? User guides, sample code, reference documentation, live demos, and tutorials are all valuable documentation formats that can help you be successful in using a library or framework.

Documentation cannot always be complete, and that's ok. You'll need to assess the needs of your organization, your project requirements, and the complexity of your software, and use that to determine the level of documentation you need.

Conclusion #

It's normal to feel overwhelmed when picking a library or framework for the first time. Just like everything else, the more you learn and practice a task, the better you become. It might be helpful to refer to this post when you next choose a library or framework to use. You can use the headings within this post as a checklist. For example: Is this library performant? Does this library meet my business standards for web accessibility?

There are other aspects of libraries and frameworks that you may wish to consider, and that have not been heavily discussed this post:

Extendibility: how easy is it to extend the library with custom logic and/or behavior?
Tooling: if applicable, does the library have tooling such as code editor plugins, debugging tools, and build system plugins?
Architecture: clean code is important, but is the overall architecture of the library sensible?
Tests: does the project have a test suite? Does the project website use badges or indicators which the test suite is passing against the latest commit?
Compatibility: does the library work well with other libraries and/or frameworks you are currently using?
Cost: what is the cost of a framework? Is it open-source or available for purchase?
Vanity metrics: this should be low down in your criteria list, or even ignored entirely, but you may wish to consider project "votes", social media accounts that represent the project, and/or how many open bugs/issues there are on the project page.

Implement error handling when using the Fetch API

2022-05-23T00:00:00Z

This article demonstrates some error handling approaches when working with the Fetch API. The Fetch API lets you make a request to a remote network resource. When you make a remote network call, your web page becomes subject to a variety of potential network errors.

The following sections describe potential errors and describe how to write code that provides a sensible level of functionality that is resilient to errors and unexpected network conditions. Resilient code keeps your users happy and maintains a standard level of service for your website.

Anticipate potential network errors #

This section describes a scenario in which the user creates a new video named "My Travels.mp4" and then attempts to upload the video to a video-sharing website.

When working with Fetch, it's easy to consider the happy path where the user successfully uploads the video. However, there are other paths that are not as smooth, but for which web developers must plan. Such (unhappy) paths can happen due to user error, through unexpected environmental conditions, or because of a bug on the video-sharing website.

Examples of user errors #

The user uploads an image file (such as JPEG) instead of a video file.
The user begins uploading the wrong video file. Then, part way through the upload, the user specifies the correct video file for upload.
The user accidentally clicks "Cancel upload" while the video is uploading.

Examples of environmental changes #

The internet connection goes offline while the video is uploading.
The browser restarts while the video is uploading.
The servers for the video-sharing website restart while the video is uploading.

The video-sharing website cannot handle a filename with a space. Instead of "My Travels.mp4", it expects a name such as "My_Travels.mp4" or "MyTravels.mp4".
The video-sharing website cannot upload a video that exceeds the maximum acceptable file size.
The video-sharing website does not support the video codec in the uploaded video.

These examples can and do happen in the real world. You may have encountered such examples in the past! Let's pick one example from each of the previous categories, and discuss the following points:

What is the default behavior if the video-sharing service cannot handle the given example?
What does the user expect to happen in the example?
How can we improve the process?

Action	The user begins uploading the wrong video file. Then, part way through the upload, the user specifies the correct video file for upload.
What happens by default	The original file continues to upload in the background while the new file uploads at the same time.
What the user expects	The user expects the original upload to stop so that no extra internet bandwidth is wasted.
What can be improved	JavaScript cancels the Fetch request for the original file before the new file begins to upload.

Action	The user loses their internet connection part way through uploading the video.
What happens by default	The upload progress bar appears to be stuck on 50%. Eventually, the Fetch API experiences a timeout and the uploaded data is discarded. When internet connectivity returns, the user has to reupload their file.
What the user expects	The user expects to be notified when their file cannot be uploaded, and they expect their upload to automatically resume at 50% when they are back online.
What can be improved	The upload page informs the user of internet connectivity issues, and reassures the user that the upload will resume when internet connectivity has resumed.

Action	The video-sharing website cannot handle a filename with a space. Instead of "My Travels.mp4", it expects names such as "My_Travels.mp4" or "MyTravels.mp4".
What happens by default	The user must wait for the upload to completely finish. Once the file is uploaded, and the progress bar reads "100%", the progress bar displays the message: "Please try again."
What the user expects	The user expects to be told of filename limitations before upload begins, or at least within the first second of uploading.
What can be improved	Ideally, the video-sharing service supports filenames with spaces. Alternative options are to notify the user of filename limitations before uploading begins. Or, the video-sharing service should reject the upload with a detailed error message.

Handle errors with the Fetch API #

Note that the following code examples use top-level await (browser support) because this feature can simplify your code.

When the Fetch API throws errors #

This example uses a try/catch block statement to catch any errors thrown within the try block. For example, if the Fetch API cannot fetch the specified resource, then an error is thrown. Within a catch block like this, take care to provide a meaningful user experience. If a spinner, a common user interface that represents some sort of progress, is shown to the user, then you could take the following actions within a catch block:

Remove the spinner from the page.
Provide helpful messaging that explains what went wrong, and what options the user can take.
Based on the available options, present a "Try again" button to the user.
Behind the scenes, send the details of the error to your error-tracking service, or to the back-end. This action logs the error so it can be diagnosed at a later stage.

try {
  const response = await fetch('https://website');
} catch (error) {
  // TypeError: Failed to fetch
  console.log('There was an error', error);
}

At a later stage, while you diagnose the error that you logged, you can write a test case to catch such an error before your users are aware something is wrong. Depending on the error, the test could be a unit, integration, or acceptance test.

When the network status code represents an error #

This code example makes a request to an HTTP testing service that always responds with the HTTP status code 429 Too Many Requests. Interestingly, the response does not reach the catch block. A 404 status, amongst certain other status codes, does not return a network error but instead resolves normally.

To check that the HTTP status code was successful, you can use any of the following options:

Use the Response.ok property to determine whether the status code was in the range from 200 to 299.
Use the Response.status property to determine whether the response was successful.
Use any other metadata, such as Response.headers, to assess whether the response was successful.

let response;

try {
  response = await fetch('https://httpbin.org/status/429');
} catch (error) {
  console.log('There was an error', error);
}

// Uses the 'optional chaining' operator
if (response?.ok) {
  console.log('Use the response here!');
} else {
  console.log(`HTTP Response Code: ${response?.status}`)
}

The best practice is to work with people in your organization and team to understand potential HTTP response status codes. Backend developers, developer operations, and service engineers can sometimes provide unique insight into possible edge cases that you might not anticipate.

When there is an error parsing the network response #

This code example demonstrates another type of error that can arise with parsing a response body. The Response interface offers convenient methods to parse different types of data, such as text or JSON. In the following code, a network request is made to an HTTP testing service that returns an HTML string as the response body. However, an attempt is made to parse the response body as JSON, throwing an error.

let json;

try {
  const response = await fetch('https://httpbin.org/html');
  json = await response.json();
} catch (error) {
  if (error instanceof SyntaxError) {
    // Unexpected token < in JSON
    console.log('There was a SyntaxError', error);
  } else {
    console.log('There was an error', error);
  }
}

if (json) {
  console.log('Use the JSON here!', json);
}

You must prepare your code to take in a variety of response formats, and verify that an unexpected response doesn't break the web page for the user.

Consider the following scenario: You have a remote resource that returns a valid JSON response, and it is parsed successfully with the Response.json() method. It may happen that the service goes down. Once down, a 500 Internal Server Error is returned. If appropriate error-handling techniques are not used during the parsing of JSON, this could break the page for the user because an unhandled error is thrown.

When the network request must be canceled before it completes #

This code example uses an AbortController to cancel an in-flight request. An in-flight request is a network request that has started but has not completed.

The scenarios where you may need to cancel an in-flight request can vary, but it ultimately depends on your use case and environment. The following code demonstrates how to pass an AbortSignal to the Fetch API. The AbortSignal is attached to an AbortController, and the AbortController includes an abort() method, which signifies to the browser that the network request should be canceled.

const controller = new AbortController();
const signal = controller.signal;

// Cancel the fetch request in 500ms
setTimeout(() => controller.abort(), 500);

try {
  const url = 'https://httpbin.org/delay/1';
  const response = await fetch(url, { signal });
  console.log(response);
} catch (error) {
  // DOMException: The user aborted a request.
  console.log('Error: ', error)
}

Conclusion #

One important aspect of handling errors is to define the various parts that can go wrong. For each scenario, make sure you have an appropriate fallback in place for the user. With regards to a fetch request, ask yourself questions such as:

What happens if the target server goes down?
What happens if Fetch receives an unexpected response?
What happens if the user's internet connection fails?

Depending on the complexity of your web page, you can also sketch out a flowchart which describes the functionality and user interface for different scenarios.

The difference between JavaScript libraries and frameworks

2022-05-23T00:00:00Z

This article teaches you about the differences between frameworks and libraries in the context of a client-side JavaScript environment, which is the code that runs in your web browser. However, some of the points raised in this article also apply to other environments because libraries and frameworks are part of many software engineering fields, such as native mobile app development.

The discussions in this post focus on the qualitative differences rather than the quantitative differences between libraries and frameworks. For example:

Quantitative: Frameworks typically adhere to the inversion of control principle.
Qualitative: The framework experience can appeal more to future employers when you hunt for jobs.

Why learn about libraries and frameworks? #

JavaScript library and framework usage is prolific across the web. Every other website seems to use some third-party code as part of its JavaScript resources. Web page weight is getting worse with time, which affects users. JavaScript is a large contributing factor toward overall page weight, and it's this same JavaScript that often comprises third-party libraries and frameworks.

It's not good enough to say, "Stop using JavaScript frameworks," because frameworks provide a big benefit to developers. Frameworks can help you to code efficiently and deliver features quickly, among other benefits. Instead, you should educate yourself so that you can make an informed decision when the time arises.

"Should I use a library or framework today?" is an uncommon question to ask yourself. Libraries and frameworks are two very different things. However, libraries and frameworks are often conflated and the more knowledge you have about the two, the more likely you are to make educated decisions about their use.

Examples of libraries and frameworks #

You might notice third-party code by other names, such as widgets, plugins, polyfills, or packages. However, they all typically fall into the category of a library or a framework. Basically, the difference between the two can be summarized as follows:

For a library, your app code calls the library code.
For a framework, your app code is called by the framework.

Library #

Libraries tend to be simpler than frameworks and offer a narrow scope of functionality. If you pass an input to a method and receive an output, you probably used a library.

Look at this example of the lodash library:

import lodash from 'lodash'; // [1]
const result = lodash.capitalize('hello'); // [2]
console.log(result); // Hello

As is the case with many libraries, it's practical to read through this code and understand what it does. There's very little magic involved:

An import statement imports the lodash library into the JavaScript program.
The capitalize() method is invoked.
A single argument is passed to the method.
The return value is captured in a variable.

Framework #

Frameworks tend to be bigger than libraries and contribute more to overall page weight. In fact, a framework can include a library.

This example shows a plain framework without a library and uses Vue, which is a popular JavaScript framework:

<!-- index.html -->
<div id="main">
  {{ message }}
</div>

<script type="module">
import Vue from './node_modules/vue/dist/vue.esm.browser.js';

new Vue({
  el: '#main',
  data: {
    message: 'Hello, world'
  }
});
</script>

If you compare this framework example to the earlier library example, you might notice these differences:

The framework code encompasses multiple techniques and abstracts them away into its own opinionated API.
Developers don't have full control over how and when operations occur. For example, how and when Vue writes the 'Hello, world' string to the page is abstracted away from you.
The instantiation of the Vue class carries some side effects, which are common when you use frameworks, whereas a library may offer pure functions.
The framework prescribes a particular HTML template system rather than using your own.
If you read further into the Vue framework documentation or most other framework documentations, you can see how frameworks prescribe architectural patterns that you can use. JavaScript frameworks take some cognitive burden away from you because you don't have to figure this out yourself.

When to use a library versus a framework #

After you read the comparisons between libraries and frameworks, you may begin to understand when to use one or the other:

A framework can reduce complexity for you, the developer. As discussed, a framework can abstract away logic, behavior, and even architectural patterns. It's especially useful when you begin a new project. A library can help with complexity, but typically focuses on code reuse.
Framework authors want you to be productive and often develop extra tools, debugging software, and comprehensive guides among other resources to help you use a framework effectively. Library authors also want you to be productive, but specialized tools are uncommon in libraries.
Most frameworks provide a functional starting point, such as a skeleton or boilerplate, to help you build web apps quickly. A library becomes part of your already established codebase.
In general, frameworks introduce some complexity to your codebase. The complexity isn't always obvious at the start, but can reveal itself over time.

As a reminder, you don't typically compare a library with a framework because they're different things that achieve different tasks. However, the more knowledge you have about the two, the more empowered you are to decide which is best for you. The decision to use a framework or library ultimately depends on your requirements.

Swapability #

You won't change your library or framework every week. However, it's good practice to understand the downsides of a package that locks you into its ecosystem. It's also recommended that you understand that the developer who decides to use a third-party package is somewhat responsible for the creation of a loose coupling between the package and the app source code.

A package that's tied to the source code is harder to remove and swap for another package. You may need to swap a package when:

You must make updates to a package that's no longer maintained.
You discover that the package is too buggy to work with.
You learn about a new package that meets your needs better.
Your product requirements change and the package isn't needed anymore.

Consider this example:

// header.js file
import color from '@package/set-color';
color('header', 'dark');

// article.js file
import color from '@package/set-color';
color('.article-post', 'dark');

// footer.js file
import color from '@package/set-color';
color('.footer-container', 'dark');

The previous example uses the third-party @package/set-color package across three separate files. If you work on this code and need to replace the third-party package, you must update the code in three places.

Alternatively, you can simplify maintenance and abstract the library usage to one place, which you can see in this example:

// lib/set-color.js file
import color from '@package/set-color';

export default function color(element, theme = 'dark') {
  color(element, theme);
}

// header.js file
import color from './lib/set-color.js';
color('header');

// article.js file
import color from './lib/set-color.js';
color('.article-post');

// footer.js file
import color from './lib/set-color.js';
color('.footer-container');

In the previous example, direct library usage is abstracted away. Thus, if you must swap out the third-party package, you only update one file. In addition, the code is now easier to work with because the internal set-color.js file sets a default color theme to use.

Ease of use #

A framework may have a complex API, but the framework could offer developer tools that make it easier to use overall. Ease of use is based on many factors and can be highly subjective. A framework can be hard to use because:

The framework has an inherently complex API.
The framework is poorly documented, and requires a lot of trial and error to solve problems.
The framework uses techniques that are unfamiliar to you and your team.

Frameworks can mitigate against these challenges through common best practices, such as these:

The framework offers developer and diagnostic tools to make debugging easier.
The framework has an active community of developers who collaborate on free documentation, guides, tutorials, and videos. After you consume this content, you're productive with the framework.
The framework offers an API that follows common coding conventions. You're productive with the framework because you learned such conventions previously and have an increased familiarity with coding styles.

While these points are commonly attributed to frameworks, they can also be attributed to libraries. For example, the D3.js JavaScript library is powerful and has a large ecosystem that offers workshops, guides, and documentation among other resources, all of which impact its ease of use.

Additionally, a framework typically prescribes an architecture for your web app while a library is typically compatible with your existing architecture, whatever it might be.

Performance #

In general, frameworks can affect performance more than libraries, although there are exceptions to this case. Web performance is a huge area with many topics, so these sections touch on two topics of note: tree shaking and software updates.

Tree shaking #

Bundling is only one facet of web performance, but it has a big performance effect, especially with larger libraries. The use of tree shaking during import and export helps performance because it finds and prunes code that's unnecessary to the app.

When you bundle JavaScript code, there's a useful step known as tree shaking that's a valuable performance optimization that you can make to your code, although it's easier to do with libraries than frameworks.

When you import third-party code into your source code, you typically bundle the code into one or a few output files. For example, the header.js, footer.js, and sidebar.js files are all combined into the output.js file, which is the output file that you load in your web app.

To better understand tree shaking, consider these code examples:

// library.js file
export function add(a, b) {
  return a + b;
}

export function subtract(a, b) {
  return a - b;
}

// main.js file
import {add} from './library.js';

console.log(add(7, 10));

For the purpose of demonstration, the library.js code sample is kept intentionally small compared to what you might find in the real world, where the library can be thousands of lines long.

A naive bundle process may export the code with this output:

// output.js file
function add(a, b) {
  return a + b;
}

function subtract(a, b) {
  return a - b;
}

console.log(add(7, 10));

Even though the subtract() function isn't needed in this app, it's still included in the final bundle. Unnecessary code like this increases the download size, parse and compile time, and execution costs that your users must pay. A basic tree-shaking approach removes the dead code and produces this output:

// output.js file
function add(a, b) {
  return a + b;
}

console.log(add(7, 10));

Notice that the code is shorter and more succinct. In this example, the performance improvement is negligible, but in a real-world app where the library is thousands of lines long, the performance effect can be much more significant. Interestingly, modern bundle tools, such as Parcel, Webpack, and Rollup go a step further because they combine minification and tree shaking to create a highly optimized bundle. To demonstrate the effectiveness of bundle tools, we used Parcel to create a bundle file with the previous code examples. Parcel removed all unused code and exported this single module:

console.log(7+10);

Parcel is smart enough to remove import statements, function definitions, and behavior among other items to create highly optimized code.

Bundling is only one facet of web performance, but it has a big performance effect, especially with larger libraries. Tree shaking is typically simpler to do with libraries than with frameworks.

Software updates #

For many libraries and frameworks, software updates add functionality, fix bugs, and ultimately grow in size over time. It's not always necessary to download updates, but if the updates include bug fixes, desired feature enhancements, or security fixes, then you should probably update. However, the more data you send over the wire, the less performant your app and the greater the performance effect on your user experience.

If a library grows in size, you can use tree shaking to mitigate the growth. Alternatively, you can use a smaller alternative to the JavaScript library. For more information, see Swapability.

If a framework grows in size, not only is tree shaking more of a challenge, but it can be harder to swap out one framework for another. For more information, see Swapability.

Employability #

It's a bit of an open secret that many companies have hard requirements for developers who know a particular framework. They may disregard your knowledge of web fundamentals and focus only on your specific knowledge of a certain JavaScript framework! Right or wrong, this is the reality for many jobs.

Knowledge of a few JavaScript libraries won't harm your job application, but there's little guarantee that it'll make you stand out. If you know a few popular JavaScript frameworks very well, there's a good chance that employers see this knowledge as favorable in the current job market for web developers. Some large enterprise organizations are stuck with very old JavaScript frameworks and may even be desperate for candidates who are comfortable with such frameworks.

You can use this open secret to your advantage. However, approach the job market with caution and with these considerations in mind:

Remember that if you spend a large amount of time in your career with only one framework, you may miss out on learning experiences with other, more modern frameworks.
Consider a developer who doesn't solidly understand software development or web development fundamentals, yet is hired as a framework developer. This developer doesn't write effective code, and you may find it daunting or overwhelming to work on such a codebase. In some cases, this scenario can lead to burnout. For example, you may have to refactor code or performance-tune the code because it's slow.
When you learn web development, the best path is to begin with a heavy focus on the fundamentals of web development, software development, and software engineering. Such a strong foundation helps you to pick up any JavaScript framework quickly and effectively.

Conclusion #

Well done on your hard work in understanding how JavaScript frameworks and libraries compare. You won't pick frameworks or libraries often unless you work on greenfield projects or as a consultant. However, when such decisions do arise, the more knowledge you have on the subject, the better informed your decision.

As you have learned, the choice of framework you make—and in some cases, the choice of library—can significantly affect your development experience and end users, such as with performance.

Umar Hansa on web.dev

Choose a JavaScript library or framework

What are JavaScript libraries and frameworks #

Example call to a JavaScript library #

Example use of a JavaScript Framework #

Why use a library? #

Why should you care about library usage? #

Performance #

Security #

Accessibility #

Conventions #

Updates #

Licensing #

Community #

Documentation #

Conclusion #

Implement error handling when using the Fetch API

Anticipate potential network errors #

Examples of user errors #

Examples of environmental changes #

Examples of errors with the video-sharing website #

Handle errors with the Fetch API #

When the Fetch API throws errors #

When the network status code represents an error #

When there is an error parsing the network response #

When the network request must be canceled before it completes #

Conclusion #

The difference between JavaScript libraries and frameworks

Why learn about libraries and frameworks? #

Examples of libraries and frameworks #

Library #

Framework #

When to use a library versus a framework #

Swapability #

Ease of use #

Performance #

Tree shaking #

Software updates #

Employability #

Conclusion #