Devographics
State of React 2023 Preliminary Discussions
EDIT: adding the link to the survey preview: https://survey.devographics.com/en-US/survey/state-of-react/2023/
Although it's still early days, we are thinking about holding our first ever "State of React" survey this year, so I'm opening this thread to collect feedback, suggestions, ideas, or anything else you'd like to share about the topic.
A few questions to get the discussion started:
- What are your biggest issues or pain points with React today?
- What do you see as major trends in the React ecosystem going forward?
- What questions would you like a React survey to answer?
- Which React libraries or tools are you most excited about today?
- Which React competitors do you think pose the biggest challenge?
I'd be curious to see thoughts from folks around:
- How they are learning new React techniques/concepts
- Preferences around rendering (CSR, SSR, etc)
- Thoughts around using/integrating frameworks in larger codebases (since that's what the core team is pushing a lot more nowadays)
- Thoughts around using/integrating frameworks in larger codebases (since that's what the core team is pushing a lot more nowadays)
Do you think you could elaborate on that? Do you mean using React within the context of Next.js, Remix, etc. as opposed to more stand-alone environments like CRA or Vite?
@SachaG loosely put: with the release of the new React docs, and the release of Next 13.4 with React Server Components integration, the React team has very firmly made it clear they want React users to build apps with frameworks that have some kind of routing / data fetching / SSR built in already (Next, Remix, Gatsby, Expo?), and not using pure SPA build setups where you have to add all the pieces yourself (CRA, Vite, your own Webpack config).
This has caused a lot of concern and frustration in the React community, as folks are confused about the benefits or intent, feeling left behind, unsure how to migrate existing pure SPAs, and concerned about non-Node backends being unable to take advantage of RSCs.
As an example, see this recent tweet thread that was based on chatter at Reactathon this last week, starting from these initial tweets (and with a dozen sub threads):
- https://twitter.com/Swizec/status/1653605092371873792
- https://twitter.com/acemarke/status/1653638787661168643
There's a couple dozen different overlapping concerns at this point, and it's pretty hard to sum up or follow the discussions :)
OK, that's what I thought. Yes I think that's probably in the top 3 concerns of the community right now, and the survey should definitely cover that.
I'd be very interested in some statistics around:
- React framework vs no React framework?
- If using a React framework, what framework? (Next/Remix/Gatsby/...)
- If not using a React framework, what bundler? (Vite/Parcel/...)
- Strict mode vs no strict mode?
- Something similar to the Features section in State of JS:
- Hooks? (
useId,useDeferredValue,useTransition, ...) - APIs? (
forwardRef,memo,startTransition, ...)
- Hooks? (
- Suspense for code splitting?
I am particularly interested to know more about React as a cross-platform solution.
Who is using which platform/renderer, for how long, and how do platforms "overlap" (ie how many React web devs are also experienced React-Native devs, React-Three-Fiber devs and vice versa)
You can preview the survey here:
https://survey.devographics.com/en-US/survey/state-of-react/2023
And here's a link to the full outline in YAML format:
https://github.com/Devographics/surveys/blob/main/state_of_react/react2023/questions.yml
You'll see there are some items commented out in the YAML when I decided to leave them out, mainly because they felt too niche or else were deprecated. But I'm happy to discuss!
This is just the first version so please take it more as a starting point than a finished product. Feedback welcome!
Thoughts / suggestions:
- Ask what version of React they're currently on? (16, 17, 18)
- Would like to see RTK Query added to the "Data Fetching" list
- Might be nice to add a "just React state" option to the "State Management" section
- Wish there was some way to differentiate between legacy "hand-written" Redux and modern Redux Toolkit
- Add React Final Form to "Forms"
- Add some form of "Effects" or "Dependencies" to the "Pain Points" list
- Add the /r/reactjs subreddit and the Reactiflux Discord somewhere in the resources sections?
@markerikson Great ideas!
Might be nice to add a "just React state" option to the "State Management" section
Maybe, although we also have useState in the features section, and I also wonder if there are any React devs who don't use useState?
Wish there was some way to differentiate between legacy "hand-written" Redux and modern Redux Toolkit
I can't think of a good way to do that, it's kind of like the Angular vs Angular.js problem… For that, the solution was to specify that we were asking about Angular and not about Angular.js with an explicit mention. I don't know if that works for Redux though? (I assume a lot of people still use Redux outside of Redux Toolkit).
Add some form of "Effects" or "Dependencies" to the "Pain Points" list
Would that be different from "Managing component re-renders"?
I can't think of a good way to do that, it's kind of like the Angular vs Angular.js problem… For that, the solution was to specify that we were asking about Angular and not about Angular.js with an explicit mention. I don't know if that works for Redux though? (I assume a lot of people still use Redux outside of Redux Toolkit).
Generally, I would hope you list both - the user experience is fundamentally different between them, and a lot of the "not happy" users are bound to be legacy Redux users, not Redux Toolkit users.
Conflating these two brings the "Redux" rating down every year and fuels a "people hate Redux" narrative that boils down to "people have not revisited the docs for 4 years and are rightfully angry that an outdated style of their library requires them to write a lot of code".
Having both in there might actually help people learn about Redux Toolkit and make the jump.
We are recommending Redux Toolkit as the default way of writing Redux since 2019. This survey should not get anyone reading the results to accidentally start using legacy Redux.
If you cannot list both, please ask about Redux Toolkit, not legacy Redux. (Although both of them individually still have - by far - more users than any non-Redux option on the list, so I really think you can justify listing both.)
Other things I noticed:
- I think you can stop listing redux-form. If you visit the homepage, you will see a deprecation note. The library is deprecated since 2019.
meta_frameworkscould also contain RedwoodJs- I wouldn't add
joi,zodoryupas "form tools" - that doesn't do them justice, they are used far beyond that. Might make sense as it's own category? animationcould also containreact-native-reanimatedhostingcould also containgeneric dockerorbare metal- that would certainly be interesting to see- maybe add React Native Radio to the podcasts?
Suggestions: A "which type of non-browser rendering" question:
- custom SSG/SSR implementation built on renderToString
- SSG with a framework/library
- classic (non-streaming) SSR with a framework/library
- streaming SSR
- React Server Components
Generally, I would hope you list both - the user experience is fundamentally different between them, and a lot of the "not happy" users are bound to be legacy Redux users, not Redux Toolkit users.
My response to this argument regarding Angular has always been "if they're so different, then they should have different names" and I kinda feel the same about Redux vs Redux Toolkit…
All things considered I do think it's more interesting to ask about Redux Toolkit then "plain" Redux though so I'll either add both, or more likely add Redux Toolkit with a note to clarify.
"if they're so different, then they should have different names"
They have different names?
Edit: I don't really know what to say here, sorry, this is not supposed to come over as snarky or anything, but they literally have different names and are different packages with different homepages, and both of those have significant adoption
I saw shadcn/ui was listed as a ui library, but it explicitly states in its documentation that it's not. You cannot install shadcn/ui. It's rather a collection of copy-pastable components.
I'd also say Tailwind CSS is not a ui library. Tailwind UI is one, but Tailwind CSS is just a CSS framework.
@phryneas I suspect that the names are similar enough that non-Redux users are not aware of the difference.
@filiptammergard thanks for the added details! But I'm not sure where else to include these two, so I don't think the distinction between UI libraries, CSS frameworks, etc. matters that much since there's so much overlap between the role they all play anyway.
Tailwind CSS should go under "CSS Tools", since it's comparable with UnoCSS, Stitches etc and not comparable with component libraries like Radix.
However, Tailwind UI is a component library that could be included in the ui library category. There's a fundamental difference Tailwind CSS and Tailwind UI that cannot be overlooked just because the naming is similar.
I get the point, I just don't think it would be useful to exclude the biggest player in this space from the category just to stick to an arbitrary classification.
Tailwind UI being a paid product (if I'm not mistaken) I think its user numbers are going to be vastly inferior to Tailwind, so we might as well feature the larger of the two imo.
@SachaG fwiw I'd definitely be curious to get a better sense of the difference in usages and feedback to "legacy" Redux and "modern" Redux Toolkit if possible. To us it is very much an Angular 1/2 kind of situation - different packages, different usage patterns, very different community feedback in which ones they like and what we're telling people to use.
It's tough, because on one hand we do want to capture as much useful data as possible, but on the other hand we don't usually differentiate between versions of the same library, no matter how big the improvements between versions.
I'm just afraid that if we start down that path, other projects could argue just as strongly that Foo.js v2 is so much better than Foo.js v1 that it's only fair to split them out, to avoid bad Foo.js v1 opinions dragging down the overall rating for the library.
Again I'm not against making exceptions to the rule if that gives us more useful data at the end of the day, but I just wanted to explain the reasoning behind my reticence.
@SachaG, I get the reasoning behind the reticence - at the same time I have to admit that whole thing hurts a bit.
As maintainers, we have been looking at these surveys for a few years now, and unfortunately, they don't give us (or anyone else) any useful data points, because they mix things together that don't belong together.
If you compared "legacy Redux" with "Redux Toolkit", it would be like comparing redux with easy-peasy, kea or rematch. Or like comparing mobx with mobx-state-tree. Or React itself with Next.js, Remix, Gatsby or Redwood.js.
Redux Toolkit is an opinionated framework for Redux.
And much like the React team, we made the decision to say "don't use it plainly, use it with a framework" - only already four years ago, and we also published that officially recommended framework ourselves, based on what we had seen crystallize as best practices over the years.
We had problems communicating that, and people kept hanging on to horrible outdated tutorials that were still teaching plain Redux, while they could only be writing 1/4 of the code (with safety wheels, much more typesafe, and without adding 25 other 3rd party packages for middleware etc.), so over the time we started referring to them as "legacy Redux" and "modern Redux", because that narrative seemed to work better to get people to actually switch over.
So maybe, based on that narrative, we somehow got you to the conclusion that RTK is just "redux 2.0", but in reality RTK bundles recommended middleware (and ships with new ones), streamlines project setup, ships new apis etc.
Meanwhile, the redux package itself published Version 5.0 beta two weeks ago. It's not like that is an "old thing" that will never get any update - we just don't want people to use it without a framework anymore.
But some do, for various reasons, and they have a significantly different experience doing so.
Honestly, having these two different libraries as two data points would maybe even help convince people to finally make the jump from their legacy code to RTK.
But yeah, if all that doesn't convince you to add both of them, the main sentiment still stands: we want people to use the framework, and it is different enough to not be thrown into one pot with the redux package. Please only mention RTK in the survey then, not "Redux" as a blanket statement.
As maintainers, we have been looking at these surveys for a few years now, and unfortunately, they don't give us (or anyone else) any useful data points, because they mix things together that don't belong together.
Just to clarify, we've never done a State of React survey before. And if you mean the State of JS surveys, unless I'm mistaken I think the last time Redux was featured as a survey item was in 2020.
@SachaG Honestly, I'm not sure which survey it was, it could also have been in a "competing" survey - but we have seen this "Redux all-in-one-bucket" again and again - and tbh., that's very frustrating, because it fires a narrative that just doesn't reflect anyone's reality. I'm extremely happy that for once we have the ability to give feedback to a survey design here before the survey happens :)
Are we supposed to open PRs at this point or only provide text feedback?
Does it also cover React-Native? If so how much? Note: there's a State of React-Native survey already.
What I would like to have is a list of "React Renderers & Platforms" people have used:
- Web
- React-Three-Fiber
- Remotion
- React-Ink
- React-pdf
- MJML-React / React-Email
- React-Native-Web (although it's an edge case it's cool to include it)
- React-Native iOS
- React-Native Android
- React-Native macOS
- React-Native Windows
- React-Native-Skia
Some quick feedback:
- Hooks: missing hook
useInsertionEffect(although it might be on purpose due to very niche usecase) - Would also separate Redux from Redux Toolkit
- Would also like having "Just React" as state management
- Would also like a schema/validation library category (joi,yup,zod,ts-io...)
- Would also like a network wiring category: (RSC, tRPC, Blitz...)
Data Loadingcould be eventually be renamed asAsync State Management? Solutions usually can handle Async browser APIs too (could be qualified as "loading"? 🤷♂️ )- Other smaller niche data loading solutions: suspend-react, react-async-hook?
- UI libraries: would be nice to feature things like React-Aria, Ariakit, Reach-ui... IMHO that's a bit similar to Headless UI.
- Frameworks: would add Redwood
- Mobile: add Capacitor? (often used with Ionic bot afaik not only)
- Build tools: turbopack, rspack? (not mainstream yet but could be useful have awareness of those)
- Backend languages: Scala, Elixir, Haskell? could be useful to see how much FP the React community is.
- Data visualization: D3, Tremor?
- CSS Tools & libs: would put Tailwind there instead of UI libs
- Other Services: Axiom, Neon, PostHog, Datadog, Segment?
- React Pain Points: debugging, performance? remove legacy synthetic events?
- Blogs & Magazines: what is React Weekly? 😅 Maybe you meant This Week In React 😜
- Podcasts: JavaScript Jam, React-Native-Radio, The React-Native Show?
- Video creators: Sam Selikoff, Jason Lengstorf, Web Dev Cody, Ben Holmes, William Candillon, notJust.dev? Some in your list do not look super related to React.
- People: some do not feel like part of the React ecosystem? 🤔 . Also hope I could be added there 😇
- Surveys: State of React-Native?
In case it's useful: list of active and qualitative (non-automated list of SEO articles newsletters for React developers:
- 50k subs: https://react.statuscode.com/
- 22k subs: http://thisweekinreact.com/
- 18k subs: https://reactdigest.net/
- 18k subs: https://reactnewsletter.com/
- 3k subs: https://nextjsweekly.com/
Thanks for the feedback!
- added Redwood
- split validation tools into their own category
- removed Redux Form
- added React Native Reanimated
- added Azure in hosting category
- added React Native Radio
- split out Redux/Redux Toolkit
- added State of React Native survey
- added
useStateto State Management section - added io-ts
- added React Aria, Ariakit, Reach UI
- added Capacitor
- added turbopack
- added Scala, Elixir, Haskell
- added D3, tremor
- react_weekly => this_week_in_react, whoops!
- added JavaScript Jam, React-Native-Radio, The React-Native Show
- added Sam Selikoff, Jason Lengstorf, Web Dev Cody, Ben Holmes, William Candillon, notJust.dev
Other points:
Suggestions: A "which type of non-browser rendering" question:
- custom SSG/SSR implementation built on renderToString
- SSG with a framework/library
- classic (non-streaming) SSR with a framework/library
- streaming SSR
- React Server Components
That seems a bit too in-depth/tricky to explain the nuances during the survey. I'm not against asking about streaming though, maybe as part of the "other features" section?
Are we supposed to open PRs at this point or only provide text feedback?
Text feedback is fine.
Does it also cover React-Native? If so how much?
Probably not too much given that there's already a survey for that.
What I would like to have is a list of "React Renderers & Platforms" people have used:
I'm not sure how many people actually use all of these apart from React Native? Maybe too niche to mention? Or else have a grab-bag "other tools" category?
Hooks: missing hook useInsertionEffect (although it might be on purpose due to very niche usecase)
Yes it seemed a bit too niche.
Would also like a network wiring category: (RSC, tRPC, Blitz...)
RSCs and tRPC are already in the survey, but not sure where to fit Blitz… maybe in the meta-frameworks category, even though it sits on top of another meta-framework?
What I would like to have is a list of "React Renderers & Platforms" people have used:
I'm not sure how many people actually use all of these apart from React Native? Maybe too niche to mention? Or else have a grab-bag "other tools" category?
Some of those renderers are quite widely used.
Even if usage is low I think a dedicated survey tab would be great for renderers and give the ability to bring awareness to the cross-platform abilities of React. Today many devs still don't know it is possible to create Desktop apps in React, or videos for example. That's to me a very important part of React and why React is successful: it doesn't even have to be the best solution on the web to win, as long as it's good enough everywhere and has a strong renderer-agnostic community. The minimum for me is to include React-Three-Fiber somewhere, it's a thriving project with an active ecosystem today.
Here's my estimation of usage per renderer:
- Web ⭐️⭐️⭐️⭐️⭐️
- React-Three-Fiber ⭐️⭐️⭐️
- Remotion ⭐️⭐️
- React-Ink ⭐️⭐️
- React-pdf ⭐️⭐️⭐️
- MJML-React / React-Email ⭐️⭐️
- React-Native-Web ⭐️⭐️⭐️
- React-Native iOS ⭐️⭐️⭐️⭐️
- React-Native Android ⭐️⭐️⭐️⭐️
- React-Native macOS ⭐️
- React-Native Windows ⭐️
- React-Native-Skia ⭐️⭐️⭐️
Eventually, we can group techs by "target":
- Web
- Mobile
- Desktop
- Emails
- TV
- CLI
- Documents (pdf, docs, slideshows...)
- Video
- 3D / VR
Would also like a network wiring category: (RSC, tRPC, Blitz...)
RSCs and tRPC are already in the survey, but not sure where to fit Blitz… maybe in the meta-frameworks category, even though it sits on top of another meta-framework?
I don't know 😅