Awesome React is 22 sections of links with no verdicts and no link checking
GitHub describes it as A collection of awesome things regarding React ecosystem. This article stays within the project description and details documented in the GitHub repository README.
At a glance
- What is it?
- Awesome React is a curated index of the React ecosystem, and reading it as a document rather than as a bookmark collection changes what you can expect from it. The entries are vendor one-liners, the section names are declared in a table of contents before any content, and the repository holds exactly two files, which is why nothing here can tell you whether a linked project still exists or whether the list itself is worth trusting as current.
- Who is it for?
- Awesome React is worth bookmarking as a map of the ecosystem, and worth reading as a directory rather than as guidance. The last push to the master branch was 2026-09-04, the repository is not archived, and the curation format is the one defined by the sindresorhus/awesome repository the title links to, so treat it as a maintained index rather than an authority.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 26 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The repository is a .gitignore and a README.md, so there is nothing to install
The complete file listing of this repository is two entries: `.gitignore` and `README.md`. There is no source directory, no package manifest, no build configuration, no test directory and no licence file. The repository metadata reports no language and an empty licence field, and it has no releases.
That shape is what an index is, and it is worth being clear about before anyone spends time looking for an API. You cannot install it, you cannot depend on it from a package manager, and there is no version to pin. Everything the project is consists of one markdown document.
The empty licence field is the part with a consequence. A curated list of links is a document you may want to mirror, fork into an internal wiki, or copy entries from, and the terms for doing that are not stated anywhere in this repository. There is no LICENSE file to read, which means the answer is not in this repository and has to come from the project that defines the format, or from an explicit decision on your side. The same applies to the blurbs, which are other people's marketing sentences reproduced verbatim rather than descriptions written by the curator.
None of that makes the list wrong. It makes it a document you read, rather than a thing you adopt.
No releases and no workflow directory, so no link is ever checked automatically
There is no `.github` directory in the file listing, which is the detail that explains a lot about how this list ages. There is no workflow configuration, and therefore nothing that periodically visits the URLs to see whether they still resolve.
Every entry in the list is a link plus a sentence, and that is the entire record. There is no version, no release date for the linked project, no star count, no deprecation marker, and no field recording when a link was last confirmed. A project that is renamed, archived, or abandoned looks exactly the same in the list as one that shipped a release last week.
This is a structural consequence of a two-file repository rather than an oversight. Link checking is the kind of maintenance that needs automation to be worth doing, and automation needs somewhere to live, and this repository has nowhere to live. So the freshness of any individual entry is a function of the last time a human opened that link, which is not recorded.
There is also no changelog. The repository has no releases and no versioning, so the history of the list is only visible in its commit log, and there is no way to ask from the document itself which entries were added when. If you are about to adopt a dependency on the strength of an entry here, the entry tells you the project exists. It does not tell you it still does, and that check is yours to make.
The blurbs are vendor copy, which is why the list cannot rank anything
Read a run of the descriptions and a pattern appears: they are the projects' own taglines. `shadcn-ui` is described as beautifully designed components built using Radix UI and Tailwind CSS. `zustand` is bear necessities for state management in React. `react-icons` is SVG React icons of popular icon packs. `rxdb` is a fast, offline-first, reactive database for JavaScript Applications. `immer` is described by what it does to state rather than by what it is.
Every one of those sentences is favourable, and every one of them was written to promote a project. That is not a criticism of the curator so much as a property of the format. A link list that reproduced vendor copy needs no editorial voice, which also means it has no basis for comparison. There is no entry in this list that says one option is better suited than another, because nothing in the format has room for that.
The consequence is that the list can tell you what exists in a category and cannot tell you which of them to pick. If you are choosing between fourteen component libraries, the information you need is the trade-off, and you are not going to find it here. The value of the list is narrowing the search space, and the cost is that you arrive at the narrowed set still holding all of the questions you started with.
Fourteen component libraries and thirteen state managers, with no ordering
Two sections show the scale and the problem at once. React Component Libraries holds fourteen entries, and React State Management and Data Fetching holds thirteen, covering redux, mobx, zustand, tanstack-query, swr, apollo-client, relay, jotai, xstate, effector, immer, immutable-js and rxdb.
Within the component list, two different kinds of thing sit side by side under one heading. `ant-design`, `material-ui`, `chakra-ui`, `mantine` and `fluentui` are complete design systems with their own components, tokens and opinions. `headlessui` and `ariakit` are unstyled or minimally styled primitives that leave appearance to you, and `react-email` is a set of unstyled components for email. `framework7` is a full HTML framework for iOS and Android rather than a React component set at all.
So the section is not a set of substitutes. Picking between a design system and a headless primitive is a different decision from picking between two design systems, and the list gives them one heading and no guidance on the difference. The same applies to the state section, where `xstate` and `effector` are logic and state-machine libraries, `immer` and `immutable-js` are data structures rather than stores, and `apollo-client` and `relay` are GraphQL clients. The alphabetical ordering confirms that no other order was intended.
The word framework covers meta-frameworks, admin scaffolds and a stated alternative
React Frameworks holds six entries, and reading their descriptions together shows that the word is doing several jobs. `next` is called the React Framework, `gatsby` builds modern websites with React, and `remix` is a full-stack web framework that lets you focus on the user interface. `react-admin` is a frontend framework for building B2B applications, and `refine` is for building React-based CRUD applications without constraints. `vike` describes itself as the Modular Framework and names itself an alternative to Next.js and Nuxt.
Three different products are being sorted into one list. Two are general meta-frameworks that own routing and rendering. Two are scaffolds aimed at admin and CRUD interfaces, where the value is a prebuilt set of screens rather than control over the stack. One positions itself explicitly against two named alternatives, which tells you the section contains competition rather than a settled default.
That is a useful map and a poor basis for a decision. The choice between owning your router and accepting an admin scaffold is the decision that actually matters, and it is not the shape of the list, because the entries are alphabetised. The one entry that argues for itself, by naming what it replaces, is also the one that has made a competitive claim rather than a descriptive one, which is a reminder to check its claims at the source.
React Native gets four subsections against React's twenty-two, and the format lives elsewhere
The table of contents declares twenty-two subsections under React and four under React Native: General Resources, Navigation, Awesome Components, and Libraries. The web side gets dedicated sections for Routing, Testing, Forms, Tables and Grids, Maps, Charts, Renderers, Internationalization, Graphics and Animations, Integration, and Real Apps. The mobile side has none of those.
The coverage ratio is the honest limitation of the list. A developer shipping to iOS and Android gets four starting points where a web developer gets twenty-two, and the categories that make web work complicated, forms, tables, routing, testing, are not separately addressed for native. The list is a survey of React for the browser with a short appendix for React Native.
The format itself is defined elsewhere. The title links to the sindresorhus/awesome repository, which is the source of the awesome list convention, and the table of contents ends with a Contribution section. So what qualifies for inclusion, how an entry should be written, and what bar a submission has to clear are all specified outside this repository, and this file is the data that results from applying those rules.
The repository is not archived and the last push to master was 2026-09-04, so the list is being worked on. What that tells you is that the entries are curated, not that each one is current.
Editorial conclusion
Awesome React is worth bookmarking as a map of the ecosystem, and worth reading as a directory rather than as guidance. The last push to the master branch was 2026-09-04, the repository is not archived, and the curation format is the one defined by the sindresorhus/awesome repository the title links to, so treat it as a maintained index rather than an authority. Two things decide whether it is useful to you. First, bring your own criteria, because every blurb in the list is written by the vendor and every one of them is favourable, so the list cannot rank anything. Second, treat React Native as a starting point rather than a survey, since it gets four subsections against React's twenty-two, and verify any link before you build on it, because there is no workflow in this repository that would have told you it had rotted.
Frequently asked questions
What does the awesome-react list actually contain?
It is a curated index of the React ecosystem described in its own words as a collection of awesome things regarding React. The table of contents declares twenty-two sections under React, covering general resources, tutorials, frameworks, component libraries, state management and data fetching, styling, icon libraries, routing, development tools, libraries, testing, components, sandboxes, forms, tables and grids, maps, charts, renderers, internationalization, graphics and animations, integration, and real apps, plus four under React Native and a Contribution section.
How do I add a library to awesome-react?
The title of the list links to the sindresorhus/awesome repository, which is where the awesome list format and its rules are defined, and the table of contents ends with a Contribution section, so submissions are invited. The formatting requirements and the bar for inclusion are not restated in the list itself, so the linked repository is the place to check before opening a pull request.
Is awesome-react still being updated?
The repository is not archived and the last push to the master branch was 2026-09-04, so it is being worked on. It publishes no releases and the file listing is only .gitignore and README.md, so there is no version to pin and no changelog. Individual links carry no last-checked date, so a link being present does not tell you whether the linked project is still current.