Open SachaG opened 1 year ago
cassidoo
commented
1 year ago I'd be curious to see thoughts from folks around:
SachaG
commented
1 year ago
- 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?
markerikson
commented
1 year ago @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):
There's a couple dozen different overlapping concerns at this point, and it's pretty hard to sum up or follow the discussions :)
SachaG
commented
1 year ago 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.
filiptammergard
commented
1 year ago I'd be very interested in some statistics around:
useId, useDeferredValue, useTransition, ...)forwardRef, memo, startTransition, ...)
slorber
commented
1 year ago 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)
SachaG
commented
1 year ago 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!
markerikson
commented
1 year ago Thoughts / suggestions:
SachaG
commented
1 year ago @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"?
phryneas
commented
1 year ago 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.)
phryneas
commented
1 year ago Other things I noticed:
meta_frameworks could also contain RedwoodJsjoi, zod or yup as "form tools" - that doesn't do them justice, they are used far beyond that. Might make sense as it's own category?animation could also contain react-native-reanimatedhosting could also contain generic docker or bare metal - that would certainly be interesting to seeSuggestions: A "which type of non-browser rendering" question:
SachaG
commented
1 year ago 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.
phryneas
commented
1 year ago "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
filiptammergard
commented
1 year ago 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.
filiptammergard
commented
1 year ago I'd also say Tailwind CSS is not a ui library. Tailwind UI is one, but Tailwind CSS is just a CSS framework.
SachaG
commented
1 year ago @phryneas I suspect that the names are similar enough that non-Redux users are not aware of the difference.
SachaG
commented
1 year ago @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.
filiptammergard
commented
1 year ago 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.
SachaG
commented
1 year ago 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.
markerikson
commented
1 year ago @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.
SachaG
commented
1 year ago 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.
markerikson
commented
1 year ago @SachaG yep, definitely understood!
phryneas
commented
1 year ago @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.
SachaG
commented
1 year ago 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.
phryneas
commented
1 year ago @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 :)
slorber
commented
1 year ago 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:
Some quick feedback:
useInsertionEffect (although it might be on purpose due to very niche usecase)Data Loading could be eventually be renamed as Async State Management? Solutions usually can handle Async browser APIs too (could be qualified as "loading"? 🤷♂️ )In case it's useful: list of active and qualitative (non-automated list of SEO articles newsletters for React developers:
SachaG
commented
1 year ago Thanks for the feedback!
useState to State Management sectionSachaG
commented
1 year ago 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?
SachaG
commented
1 year ago Also updated the People list, and added a new question about AI Tools.
slorber
commented
1 year ago 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:
Eventually, we can group techs by "target":
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 😅
SachaG
commented
1 year ago OK, I added the Renderers question. At this point I think the survey is looking fairly complete, and we should probably start thinking about things to cut down rather than things to add, especially from the "Other Tools" section which is looking quite full… Who knew the React ecosystem was so large!
filiptammergard
commented
1 year ago I still really think Tailwind should be moved from UI libraries to CSS tools. When people talk about Tailwind it's almost always the CSS tool (comparable to the ones in the CSS tools section) and not the Tailwind UI component library.
People will definitely find it strange not being able to choose Tailwind in CSS tools section when they can choose UnoCSS, Vanilla Extract etc.
SachaG
commented
1 year ago OK I'll make that change too.
SachaG
commented
1 year ago Btw, I wonder if we could find more questions to identify how the community feels about the current shift towards Next.js/RSCs/meta-frameworks/etc. as discussed in this thread and on Twitter.
To me it seems like there's two distinct axes that people disagree on, the "amount of work" axis and the "amount of value" axis. The React team would probably argue that RSCs don't require a ton of work to add to your app and bring a lot of value, while the negative case would be that they do require a lot of work for not that much in return. Maybe we could find a way to phrase questions around that concept?
slorber
commented
1 year ago Wonder how useful collecting the sentiment of the community on this topic would be. It's probably a bit too new and people haven't actually used RCSs in production for real world websites.
I forgot to also mention these newsletter:
Unrelated but was wondering if this button for long lists wouldn't bias the survey toward the first list items.
I don't really have a better solution with decent UX 😅 Maybe the "sample" before that button is pressed could be made more visible, or the sample could be randomized?
SachaG
commented
1 year ago Unrelated but was wondering if this button for long lists wouldn't bias the survey toward the first list items.
Yes, it's a risk. For lists featuring more subjective items (pain points, etc.) the items are randomized. For things like e.g. Podcasts I assume that you either listen or don't listen to a podcast, so I just order them alphabetically and hope it won't impact the data too much.
charkour
commented
1 year ago As of Node v18 and v16.17.0, there is a test runner built into Node. Is it too niche to add to the testing tools? https://nodejs.org/docs/latest-v20.x/api/test.html
charkour
commented
1 year ago Also, I know bootstrap CSS has fallen out of favor but it's still widely used. I know you've taken it out of past surveys, but I wanted to throw out the idea. Thanks!
SachaG
commented
1 year ago Thanks for the suggestions! I believe we do have react-bootstrap as one of the options.
leerob
commented
1 year ago For Other APIs
For State Management
Data Loading
Metaframeworks
AI Tools
For Pain Points
New Features
SachaG
commented
11 months ago Since it's been a while since I last worked on the survey I decided to revisit it and simplify it a bit, in the hopes of launching it imminently. Here's the updated version: https://survey.devographics.com/en-US/survey/state-of-react/2023
filiptammergard
commented
11 months ago I think it looks really good! 👍
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: