Based on DataMost Popular React Tech Stack in 2022

Johannes KettmannPublished on 

If you want to start a career as a React developer you're faced with a difficult decision: What libraries and tools should you use for your next project? The React ecosystem is huge. There's always a new hype and way too many contradicting opinions. How confusing...

The decision is simple though: focus on the most popular libraries and tools. Likely these are also widespread in real-world projects. This way you'll increase the chances of your tech stack matching the requirements of a job.

The only problem is: What is this tech stack? You probably guessed it. The answer is on this page.

This article gives you a list of the most important libraries and tools used in the React community. A somewhat objective list. Not based on a single opinion but based on download stats, surveys, and community discussions.

A quick note on methodology

The main data source used in this article is weekly download stats from npm.

Admittedly, this is not the ideal data source. Most downloads are caused by CI pipelines. But It's unclear who contributes to what extent. Some teams have CI that downloads fresh packages frequently. Others use caches and rarely need to download anything from npm.

Nevertheless, download stats are one of the most objective and fine-grained measures for popularity that we currently have. Especially when we take them to compare different packages relative to each other.

In combination with other data sources like the State of JS survey, community polls, or discussions we get a solid overview of the most popular choices in the React ecosystem.

When you look around in online communities you can frequently see questions like

  • “Next.js vs Gatsby vs Remix? Which one should I use for my project” or
  • “Should I use Redux in my project?” with different opinions ranging from “Just use Context” to “Zustand is much better”.

This can be super confusing. So in this first section, we’ll get an overview of the most important libraries for different use-cases like state management, forms, or styling.

You know the basics of React but have no clue how professional dev teams work?

Don't just follow a video instructor. Build a production-grade project on your own with professional workflows, designs, and tasks. Sign up today to secure your launch discount.

Source:, Jan 2022

We can see that Next.js is a clear choice. Gatsby seems to be stagnating while Remix (despite the current hype) is still in its very early shoes. It'll probably be hard to find a job where Remix is used in the foreseeable future.

It's interesting to note the high weekly download numbers for Next.js with 2M. Compare this to 14M weekly downloads of React itself. The point is, that Next has become the go-to framework for building React apps.

That's not a surprise. Next.js offers many benefits like server-side rendering or code splitting without complicated a Webpack setup. It is very mature and thus safe to use in production.

This comment from a discussion about starting a project with Next.js vs Create-React-App says it all:

Just a few years ago the standard for state management was without a doubt Redux. Nowadays it seems that more and more people complain about it and recommend other libraries like Zustand or Jotai.

Source:, Jan 2022

But the download stats paint a different picture. Redux is by far the most used state management library out there. Only the native Context API seems to get close as shown by this poll.

The comments below the poll also indicate that Redux is especially prevalent in the professional world.

In recent years there have been more and more complaints about Redux as you can see in many discussions and the satisfaction ratio in the State of JS 2020 survey:

Many of the negative comments stem from older versions of Redux. Nowadays it’s recommended to use Redux Toolkit (RTK) since it’s much easier to set up and removes a lot of boilerplate. You can even combine it with Redux Toolkit Query for data fetching.

Adoption of RTK seems to increase quickly as it's the second most downloaded package in the chart above. It looks like 1 out of 6 websites built with Redux uses RTK now.

Source:, Jan 2022

According to these stats Apollo seems to be the most popular choice when it comes to data fetching. There’s even another 1M weekly downloads of the legacy version apollo-client that I omitted here.

The problem with Apollo: It’s built for GraphQL APIs.

That’s where react-query comes in. It’s a relatively new library that has gained momentum quickly. It’s very popular among developers and you can use it to connect to any kind of API. It handles many common use-cases like caching or retries.

Since react-query is the more versatile option, I’d recommend it as the go-to library for data fetching. If you use a GraphQL though, have a look at Apollo.

There’s a notable third option that makes sense if your app already uses Redux Toolkit: RTK Query. It has similar features to react-query and is included in the @redux/toolkit package. Because it’s not a standalone package the download numbers are not shown in the above graph and it’s hard to tell how widely it’s used.

To summarize let me refer to an comment by Mark Erikson (one of the maintainers or Redux):

I would recommend not hand-writing data fetching code no matter what you're using. If you're already using Redux, you should probably use RTK Query. If you're using just React, you should probably look at React Query.

Source:, Jan 2022

Based purely on the download numbers the most widespread form libraries are Formik closely followed by React Hook Form. But it's obvious that the latter is quickly increasing adoption.

Judging from the love it gets in this and other discussions React Hook Form is a clear choice.

Note: you don't necessarily need a form library. Many simple forms can be handled without any state management as Swyx or Josh W. Comeau suggest.

According to this poll, roughly half of the professional world uses component libraries and the other half writes custom CSS (the lower two bars combined).

Some developers complain that component libraries like MUI aren’t flexible enough while others state that it doesn’t make sense to reinvent the wheel. But whether a product is built with a component library is always a trade-off between custom design and cost of implementation/maintenance.

According to the comments below the poll, the most used libraries seem to be styled-components (for custom styles) and MUI (as component library). Let’s compare that with the download numbers.

First the two most popular CSS-in-JS solutions:

Source:, Jan 2022

For custom styles, CSS-in-JS solutions have been on the rise for some time with styled-components being the most popular and Emotion quickly picking up. Both are very similar so it doesn't really matter which one you pick. If you don’t want to create all components from scratch you can use custom styles in combination with a headless component library like Headless UI.

Source:, Jan 2022

Among component libraries MUI (former Material UI) seems to be the most widespread. Note that you need to add the green and the yellow lines because of the recent name change from Material UI to MUI.

If you have to decide between learning CSS or a component library I’d personally follow this commenter:

Use these libraries hands-on while working on a professional project.

Don't just follow a video instructor. Build a production-grade project on your own with professional workflows, designs, and tasks. Sign up today to secure your launch discount.

Most professional teams use tools in their IDEs and CI pipelines to catch bugs early on and to increase code quality/readability. Here are the download numbers of the most important tools.

Source:, Jan 2022

As you can see TypeScript, Prettier, and ESLint are all on a similar level regarding the download numbers. It’s important to note that these tools are used throughout the JS community and are not restricted to the React community.

I’ll quickly explain each tool in the following sections.

Prettier (for code formatting)

Prettier is an opinionated code formatter. It’s been around for years and is widely used. As you can see in this screenshot of the Prettier playground you can write really ugly code and Prettier will make it look nice.

Using a code formatter ensures that every developer on the team sticks to a certain code style. That results in more coherent code and improves readability.

Since it’s easy to use I’d suggest you adopt it in your personal projects as well. You can attach it to your editor’s “Format on save” functionality.

ESLint (to catch problematic patterns)

A linter like ESLint statically analyzes your code, detects problematic patterns, and enforces best practices. It can warn you that your code contains bugs before you release it. Like in this example:

ESLint is very customizable. But it’s better to follow a standard by using a popular preset.

Which preset to use? Airbnb was long the default but many feel it’s too prescriptive. Rather use the default eslint:recommended settings in combination with Prettier.

TypeScript (for type checking)

TypeScript has seen vast adoption in the professional world. A good indicator is its usage ratio in the State of JS 2020 survey: 78% of the participating developers have used TS.

The React community seems to be pretty united on the TS side as you can see in this discussion about learning TypeScript:

Personally, I rarely see a React job offer without mentioning TypeScript nowadays. Which doesn’t mean that it’s a requirement to get the job (especially for Junior devs) but rather that TS is a common tool in the tech stack of companies.

The reason for this adoption is that TypeScript helps you detect problems with your code while you write it (similar to ESLint). But while ESLint focuses on conventions and finding problematic patterns TS goes a bit deeper. Have a look at this example:

To ESLint this doesn’t seem like a problem. But it’s clearly wrong since a number doesn’t have a method toUpperCase. This code would pass our linter and introduce a bug.

TypeScript checks the type of the variable. It knows that text is a number (and not a string as the name suggests). Thus it complains that the function text.toUpperCase doesn’t exist:

Build a project using this set of professional tools.

Don't just follow a video instructor. Build a production-grade project on your own with professional workflows, designs, and tasks. Sign up today to secure your launch discount.

ESLint and TypeScript are the first safeguards against bugs by statically analyzing your code. Automated tests are the third safeguard.

Automated tests ensure that the features of your app work correctly. This is particularly helpful to prevent regressions (meaning bugs introduced by changes to existing code).

The testing landscape appears to be fragmented at first glance. These are the usage ratios of different testing libraries according to the State of JS 2020 survey:

This looks like quite a handful at first but we can group and compare them by different use cases.

  • Test frameworks: Jest vs Mocha vs Jasmine
  • Utility libraries for testing React components: React Testing Library vs Enyzme
  • End-to-end tests: Cypress vs Puppeteer vs Playwright
  • UI testing and documentation: Storybook

Source:, Jan 2022

As you can see, Jest is the most used test framework in the JS testing landscape. If we narrow down on the React community Jest is probably even more predominant. I personally don’t know any React project that uses Jasmine or Mocha in favor of Jest.

Jest is mostly used for unit tests (e.g. of business logic) or as the underlying test framework in combination with utility libraries like React Testing Library.

Source:, Jan 2022

Even though Testing Library shows a low usage ratio in the survey from 2020 it has clearly taken over as the go-to library for React tests according to the download stats. This commenter points it out well.

React Testing Library is used to write integration tests. That means you don’t test every component in isolation but integrated with the system (e.g. a page or larger parent component). Most tests in a React application are typically integration tests.

Note: If you want to learn more about the different types of tests check out this blog post by Kent C. Dodds.

Even though it’s still in use, the predecessor of React Testing Library (also RTL) called Enzyme is dead by now. You’ll still find a lot of Enzyme tests in the wild but their usage will decrease in the future when more and more projects are updated to newer versions of React.

Source:, Jan 2022

End-to-end tests (also e2e-tests) are used to test the whole system from frontend to database. These tests ensure that everything works together.

The most popular tool for e2e-tests according to the download stats is Cypress with Puppeteer as the closest competitor. I personally have seen many teams adopt Cypress and can highly recommend it. You can watch the tests in a browser and time-travel through every step. This makes Cypress a great choice if you’re new to testing.

Since Storybook basically doesn’t have a competitor, let’s add React Testing Library and Cypress to illustrate how frequently it is used in the real world. Note that Storybook and Cypress are framework-agnostic.

Source:, Jan 2022

The download numbers of Storybook are even higher than the ones of Cypress. Storybook’s competitor react-styleguidist is basically non-existent in comparison. And according to its website, a lot of big-name companies make use of it.

You wonder what Storybook is about?

In large apps, you can find thousands of components. So it’s really hard to keep an overview and the risk of duplication increases. Storybook solves this problem. With Storybook, you can create components in isolation and run them in a separate environment. You can easily test them by changing e.g. the props and screen sizes via the UI.

Get experience with testing while working on a professional project.

Don't just follow a video instructor. Build a production-grade project on your own with professional workflows, designs, and tasks. Sign up today to secure your launch discount.

Trunk Based Development (Git workflow for collaboration)

Apart from specific tools and libraries, almost every developer team relies on Git for version control, collaboration, and integrating tools like linting, type checks, and tests into their automation.

There are a handful of different Git workflows out there. A few years ago I mostly heard of Git Flow. But now even the original creator discourages using Git Flow for most web apps on his website:

Web apps are typically continuously delivered, not rolled back, and you don't have to support multiple versions of the software running in the wild. [...] If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

From my experience, trunk-based development is the most common and popular Git workflow used in professional teams building web apps (although I can’t base it on numbers, unfortunately). It’s very similar to the GitHub Flow mentioned in the quote above. In short, it works like this:

  1. Create a new branch from the main branch.
  2. Commit your code on this branch and push it to the remote repo (e.g. on GitHub).
  3. Open a Pull Request (aka Merge Request) in the remote repo.
  4. Run linter, type checks, and tests.
  5. Let your team members review your code.
  6. Merge the branch into the main branch.

You can learn and experience trunk-based development/the GitHub Flow in my free course by playing Minesweeper with a bot.

Step 4 is automated with a Continuous Integration (CI) tool. Nowadays GitHub Actions seems to gain more and more popularity because of its simple integration with GitHub.

The goal of the CI and the code reviews is to catch as many bugs as possible before the release and improve the readability, coherence, and quality of the code.

Summary: An advanced React learning path

Once you covered the basics of React the best way to advance your skills is by building projects. To make the best of your time you can approach your projects like a professional using the list of tools and libraries above.

Here is a suggestion for your next project’s tech stack.

1. Learn Trunk Based Development

As a foundation of your development workflow, learn about Trunk Based Development and use it in your project. You can get your first hands-on experience with my free course by playing Minesweeper with a bot. It only takes an hour or two.

2. Use Next.js

Set up the project with Next.js by running npx create-next-app@latest. Next.js adds some magic around React but it’s fairly easy to get started. You can simply edit or add pages in the pages folder like any other React component and learn the advanced features step by step when it’s required. If you want a bit more guidance you can also start with this official tutorial.

3. Optional: Use TypeScript

I don’t think knowing TypeScript is expected by a Junior developer. But if you know some TypeScript already or you’d like to give it a try initialize the project via npx create-next-app@latest --typescript.

In my opinion, it’s not necessary to force yourself to learn TS if you have a lot on your plate already. It can be pretty annoying to use in the beginning and slow you down a lot. If you work on an existing TS project though it can be a lot easier to pick up since you can peek at the type definitions of other developers and ask them for help.

4. Use ESLint

Next.js comes with ESLint preinstalled. Adding eslint:recommended in addition to the default next/core-web-vitals might be a good idea to have a somewhat stricter set of rules.

5. Use Prettier

It helps to get used to a clean code format from the beginning. Here are instructions on how to use Prettier together with ESLint in a Next.js app.

6. Use styled-components or MUI

At least in one of your projects write custom styles to sharpen your CSS skills.

The default Next.js app uses CSS modules out of the box. You can keep using it if you have a lot to learn already. Otherwise give styled-components a try.

If you want to use a component library pick MUI since it’s the most widespread.

7. Write tests with Cypress

Write at least a few tests either with React Testing Library or Cypress. This will let you stand out from other Junior devs.

Similar to TypeScript, starting to write tests can be a huge pain, unfortunately. Cypress has a few advantages here. Compared to React Testing Library (RTL)

  • it requires less setup (you simply run your app and visit its URL in the test)
  • it has a lot of great features that make it intuitive to debug your tests.

For example, you can watch your tests run in the browser and time-travel by clicking through each step. You can even use Cypress Testing Library on top so you already know the API of React Testing Library.

So even though most tests for a React app are typically written with RTL it might make sense to start with Cypress if you’re new to testing.

8. Optional: Use Redux

Add Redux if your application has global state. If you build a project for your portfolio or simply as practice you can use Redux without a second thought. Redux is so widely spread in real-world apps that it’s useful to get some hands-on experience in any case. If you want to build a production app on the other hand you might want to consider this advice.

9. Optional: Use Storybook

Since it’s used in many projects it can make sense to add Storybook to one of your projects. It will definitely add a professional touch. And that in turn might impress a hiring manager.

Similar to testing it’s enough to document a few simple components just to get the hang of it.

You would like to build a professional React project with this tech stack?

Don't just follow a video instructor. Build a production-grade project on your own with professional workflows, designs, and tasks. Sign up today to secure your launch discount.