Devographics
State of React 2024 Preview
- https://survey.devographics.com/en-US/survey/state-of-react/2024
Also see previous suggestions here: https://github.com/Devographics/surveys/issues/243
State of React 2024 Feedback
Main
- act() test API is missing. Maybe on purpose but it seems on par with <Profiler>
- Suspense is missing, it was introduced in React 16.6 (although less powerful at that time)
Hooks
- useDebugValue missing. Maybe on purpose.
- useImperativeHandle missing. Looks like this one could be added
- useInsertionEffect missing. Maybe on purpose
- useLayoutEffect missing and should definitively be added
- Are useTransitiion, useDeferredValue missing? Those APIs are available in React 18 to turn on Concurrent React.
New APIs
- Would probably rename the section to New Features. Server Components are not really an API for example, but more of a bundler-level feature.
- I’m not sure if Suspense, useTransition and useDeferredValue should appear in that New section. Maybe worth consulting the React core team on their opinion.
- React.cache(): worth asking the React team about it. Afaik it’s not planned to land in v19.0
Component Libraries
- Probably many more UI libs but it’s probably not worth including all of them. I’d still add Ariakit, and maybe specialized libs like Downshift, react-select, react-table, react-dnd
- Animations: React Transition Group, Lottie?, gsap uppercase GSAP?
- Forms: maybe include react-select and downshift here?
- Forms: I would find it interesting to have some kind of “Form Practice” question and add uncontrolled + controlled choices including positive/negative feedback on each
- Styling: I would add CSS loader (just importing CSS files), StyleX, PandaCSS, React-Native-Web
State Management
-
Technically async libs like React Query might be considered state management, but that’s probably ok to keep it this way.
-
I would also add the React Context API in this category because it’s often used alongside other small libs (Zustand, useState) to provide “global” state management.
Data Loading
- Would replace Fetch/Axios by useEffect. You can use those libs as an implementation detail of fetching with useEffect, but also with React-Query, SWR etc.
- If Fetch/Axios are there, you could also include ky, got, superagent. Maybe group these options together as a “Network lib API” or something?
- Would add suspend-react as a popular solution in the R3f community
Backend & Infra
- Docusaurus? Maybe not the choice users would give on a “free input field” but they’d probably click on it if the option was presented. We have more dl than Gatsby, Astro, Redwood, TanStack Router
- Add a comment in Remix such as “including React Router using with the new Vite plugin”, since Remix is kind of merging back into React Router the line is blurry.
- Tools: Bun Bundler, Rspack
- Hosts: Deno
- Services: there are too many! Neon, MongoDB Atlas, Hasura, S3…
Other Tools
- Validation: JSON Schema, Effect, ArkType (new but promising)
- Auth: Better-Auth (new but promising)
- Mobile: Tauri (v2 has new mobile support, been cooking for a while). I’d rename the section “which frameworks” and not “which libraries”
- Other frameworks: HTMX, Web Components
Usage
-
Use React for: I feel like the very important “dynamic content site” option is not really present here. As an e-commerce or marketing CMS-based-site, I’m not static and I’m not really an app either. There’s a big difference between an app (SPA, can show spinner on load) and a site that need SEO, perf and great loading UX. I’m not sure to understand the difference between desktop app (electron?) and web apps (figma? e-commerce?).
-
Rendering patterns: I’m not sure many will know if they even use features such as “progressive hydration” or “streaming SSR”. They might keep it unchecked despite using it if they don’t have the option “I don’t know what it is”
Most excited about:
- React Forget -> renamed as React Compiler
- Server Actions -> renamed as Server Functions
- Offscreen -> renamed as Activity (but worth mentioning Offscreen as a former name)
- Suspense / transitions not really new, but why not?
- My addition: Optimized Context subscriptions. The React team is likely to optimize context reads/re-renders in the future with a better solution than context selectors. It’s worth asking them how to present this choice and its name, although the React community is obviously super interested to have such feature. More context in this article and this tweet
Resources
- Podcasts: Front-End Fire, Rocket Ship, This Month in React (Reactiflux), Frontend First, these 4 are more Reacty than many others
About You
N/A
There are React design decisions that @rickhanlonii could probably advise us on, such as:
- is it worth including less common APIs such as
useInsertionEffect,act(),useDebugValue,useImperativeHandle? - is it worth including
React.cachein this year's survey? I thought it was not planned for v19.0 but apparently it's documented already. - is it worth including React integration methods:
hydrateRoot,renderToString,renderToPipeableStream... ? - do
Suspense,useTransition/startTransition,useDeferredValuebelong to the "New APIs" section - is it worth presenting "progressive hydration" and “streaming SSR” as a binary checkbox choice (I used it / I didn't)
- are there 2 distinct checkboxes for Server Functions and Actions?
- should "optimized context subscription" (
useMemo+use) be mentioned as an exciting upcoming feature?
Server Actions -> renamed as Server Functions
Server Actions still exist. The "parent" category is called Server Functions, implying there will be other function-like things that, well, run on the server. So I'd recommend keeping Server Actions.
React.cache()isn't going anywhere AFAIK.- Not sure if this is confusing, but you might consider "URL State" as an option for state management.
- For Data Loading, maybe consider adding "Frameworks" as an option there? e.g. Next/Remix
- Frontend First under podcasts?
Awesome feedback! Also as a more general point, beyond simple features/libraries/etc. questions, I'm also happy to consider more targeted questions that might help address specific issues that the Next.js, React, etc. teams might be having. e.g. it could be something like "what are the obstacles preventing you from adopting RSCs in your codebase", etc. if that happens to be a topic you guys would like to learn more about.
First thanks @slorber for this extended feedback which is awesome :eyes:
Regarding Application patterns, we could simplify and stick to most common patterns, and maybe provide a free text for "your favourite pattern this year" (eventhough that's more work for us). The current list mixes framework specific wording like islands, patterns that are slightly redundant etc.
I would propose:
- SSR/dynamic rendering at request-time
- SSG/static rendering at build-time
- Hybrid rendering patterns: incremental/on-demand rendering, static with revalidation, dynamic rendering with caching...
- SPA/view transitions: pure client-side routing
- MPA: pure server-side routing
- Edge : rendering or altering rendered HTML at the edge, redirecting or rewriting URLs
Basically I removed stuff that are automatically brought by the framework, eg streaming SSR or island, and focused on patterns that are actual decision from the user
NP 👍
The question I find the most confusing is not the Application Pattern but the React usage one. I wouldn't know how to classify an e-commerce/media/marketing/blog/cms-based content site.
Maybe it could be useful to explain what you mean for each option. For example: Desktop apps (Electron or corporate web backoffice app?), Web apps (websites included?).
Maybe adding a "Web sites" option, and a description for each option would be useful?
For application patterns, I don't really know what's best.
What I don't like is to present boolean choices to things that are implementation details, and that users may not be aware of using. The boolean choice (yes/no) might bias the results. All the options would be fine if there was a way to answer "I don't know"
SPA/view transitions: pure client-side routing
I find this option a bit confusing because of cross-docuent view transitions, it also works for MPA despite not using pure client-side routing
- ➕ adding
act - Suspense is there, but in the "new APIs" section. Should it be moved to "main APIs"?
useDebugValueseems a bit too niche?- same for
useImperativeHandle - same for
useInsertionEffect - ➕ I didn't include
useLayoutEffectbecause of the warning in the docs. But if you think it's important I'll add it. useTransitionandusedeferredvalueare both included
I’m not sure if Suspense, useTransition and useDeferredValue should appear in that New section. Maybe worth consulting the React core team on their opinion.
- Don't have a strong opinion on that, I'll default to leaving them as is for now.
Forms: I would find it interesting to have some kind of “Form Practice” question and add uncontrolled + controlled choices including positive/negative feedback on each
- ➕ Good idea! I'll add that.
- UI libs, styling libs, etc.: I try to only include the most prominent items for each question, otherwise the lists of options get overwhelming.
I would also add the React Context API in this category because it’s often used alongside other small libs (Zustand, useState) to provide “global” state management.
I'm kind of leaning towards removing useState rather than adding Context to be honest. I think it's kind of an unfair comparison to include a core API among libraries, although I added it to have a baseline of sorts.
Would replace Fetch/Axios by useEffect. You can use those libs as an implementation detail of fetching with useEffect, but also with React-Query, SWR etc.
I think it'd be confusing to have useEffect here. Maybe instead some generic term like "generic data loading library" or "network library" like you suggested?
Add a comment in Remix such as “including React Router using with the new Vite plugin”, since Remix is kind of merging back into React Router the line is blurry.
This reminds me of the Angular.js vs Angular situation… I'll think about it but I think it'd be better for everybody to keep the "Remix" brand alive to avoid confusing people.
Great 👍
useInsertionEffectis clearly niche and I don't know anyone using ituseImperativeHandleis more commonuseLayoutEffectis very common despite the docs warning
I think it'd be confusing to have useEffect here. Maybe instead some generic term like "generic data loading library" or "network library" like you suggested?
To me useEffect for data fetching is directly comparable to react-query, swr and others that are just abstractions build on top of it. You can use all 3 with fetch or Axios. Separating data loading from network lib might be better indeed.
We're live!
https://survey.devographics.com/en-US/survey/state-of-react/2024
Sorry, I know this was all a bit short notice, but I'm trying to get all the surveys out before the end of the year.
By the way, if you're able to share the survey (which would be very helpful!) please include a ?source=foo tag at the end, such as:
https://survey.devographics.com/en-US/survey/state-of-react/2024?source=this_week_in_react
This will help us track where respondents are coming from, and see if it influences their answers in any way.
Under component libraries, I noticed that React Aria is the only one that has a description, not sure why that is. It is also using a bit of an outdated description, since React Aria is not only hooks anymore, it's also components. Think we can update that to avoid confusion (i.e. people might think this is only referring to the hooks and not the components)?
New description, from readme:
A library of unstyled React components and hooks that helps you build accessible, high quality UI components for your application or design system.
@devongovett yeah I need to remove library descriptions from the survey itself I think, they were meant for the survey results originally.
Update: the survey is now live! (and has been for ~10 days, actually)
- https://survey.devographics.com/en-US/survey/state-of-react/2024
It'd be a huge help if you can share it with your audience, especially @leerob !
yes, looks like the meta is wrong @SachaG : https://assets.devographics.com/surveys/react2024-og.png
should be https://assets.devographics.com/surveys/react2024.png ?
Thanks @slorber I was exactly on it this morning ^^ so the "-og" variation is missing in our images repository. It's not so easy to detect automatically, as I would need to send a request to see if the URL exists. And it won't fallback automatically to another image, because we do have a non empty URL in the placeholder.