Late last year, we decided to run an end-of-year survey to discover and celebrate what the community has been up to with React Flow, but also to uncover the current pain points in both the library and our documentation. This has already helped serve as a compass in the beginning of this year as to what to work on next that will be of most help to our users.

Now 2024 is getting away from us, and it’s time to share what we found! This report serves two purposes:

1. To share the results of the survey with the community! In particular we think it’s great to celebrate all the different people and projects that are using React Flow.
2. To help other open source projects understand what sort of insights they might be able to gain from running a survey of their own.

If you just care about the high-level results, we have a fun interactive React Flow app that shows off the highlights. Otherwise, keep reading for the full scoop.

Our method

Any good survey starts with a clear goal in mind, and we did our best to make sure that we were asking the right questions in the right way. We put together a survey using Typeform (did you know they use React Flow?) that would help us learn about our community in five important areas:

1. Who our users are and what is their expertise. We know our users come from all sorts of backgrounds and we’re often discussing how to make sure our content serves everyone (that’s how we ended up with our super quick TypeScript primer for JavaScript users). Getting a better understanding of who our users are means we can rely less on our gut feeling and make sure we’re tailoring our content to the right people.

2. What they are building with React Flow. We love seeing all the cool things people are building with React Flow! We wanted to know what sort of projects people are working on to see if there were any unexpected use cases that we could learn from or what common types of apps we could focus our development and documentation efforts on.

3. Where our users go to get help. We spend a lot of time on our documentation so it’s important to know that time is being spent in the right places. We have analyticis to tell us what pages are popular, but if folks are heading somewhere else to get help then that can tell us something too!

4. What features or things do they find most difficult about React Flow and what would they like to see added. Gathering feature requests is a no-brainer for a survey like this – especially as we wrap up work on React Flow v12 and set our sights on the future. But it’s also useful to learn about the pain points folks run into when using the library, especially if we can factor in their different backgrounds and use cases.

5. What our users think about React Flow Pro, why they would or would not subscribe, and what they think about the pricing. It can feel a little uncomfortable to talk about money in an open source project, but our Pro subscribers keep the lights on and make sure we can can keep working on the project. That being said, it’s important to us that our regular users (that make up the vast majority of our community) don’t feel like we’re squeezing them for cash or holding features hostage. This vibe check can tell us if we’re communicating what React Flow Pro is about effectively.

It’s easy to fall into the trap of asking questions and collecting data that you don’t need. Working out the gender split of React Flow users might be interesting, but “because it’s interesting” is not a compelling reason for research! Keeping these goals in mind helps us focus the questions and make sure we’re collecting information we can make use of.

There’s always a balance between wanting to capture the most information possible and making sure that the survey is short enough that people will actually take some time to fill it out. We designed the majority of the survey questions to be multiple choice (with many optionally including a free-form “other” response) and left the most important questions open-ended.

The Survey

The survey ended up being 19 questions long, and took a little less than 10 minutes to complete. We had a total of 86 responses and worked out we had a 42.2% completion rate: that means about 200 people started the survey and roughly 120 of them didn’t finish it. A completion rate of 42% is actually pretty good for a survey like this!

What we found

Who is using React Flow?

We mentioned in the previous section that discovering things like the gender split of our community weren’t important to us, so what sort of information did we collect?

Firstly, we found that 57% respondents are new to React Flow (using it for less than six months). Folks new to the library/community might be more engaged and willing to provide feedback.

Most respondents said their role or area of expertise was full-stack and/or front-end, which is to be expected for users of a front-end library. That being said, we did have four people who only selected “back-end” as their area of expertise. We even had some respondents from data science and design backgrounds: not even developers! This aligns with interviews we’ve done and anecdotal evidence that React Flow is some folks’ first foray into the world of React and/or front-end development. No wonder so many people mention difficulty with state management! (We’ll get to that later.)

81% of respondents were using React Flow at work, which shows that it’s been battle-tested for real world applications. 33% were using it on personal projects.

What are people building with React Flow?

We are always interested and excited to see what people build with React Flow. Knowing what sorts of things people are building guides us to build relevant examples and documentation for common use cases. We took the wide variety of answers and clustered them into an affinity diagram, which gave us a lay of the land on what React Flow is being used for.

We were surprised to see the number of whiteboard or infinite-canvas style apps users were building with React Flow. This has got us thinking about what examples we can provide to help support this kind of use case, even if this kind of tool wasn’t our original intention behind building the library.

We were also surprised to see how much internal tooling was being built the library. Often internal tools can be a bit unglamorous, but this turned out to be one of the largest categories! The features we’ve added for computing flows in React Flow 12 should help these folks a lot.

We confirmed what our show-and-tell discord channel and showcase have already told us: that lots of folks are building workflow builders and no-code tools. We knew this from the many projects we see on our discord and in our showcase. This includes a bunch of AI tools, which is also no surprise.

We saw a number of folks using React Flow to build engineering-heavy tools, which we were excited to see, because these use cases can challenges us to build more technical-specific use cases in our examples, or maybe even build templates. We know a lot of heavy node-based engineering tools are built for desktop applications (so they don’t use javascript), but maybe we lure some products over to building lighter web apps with some enticing technical-heavy use cases.

Next year, we’re interested in seeing how this landscape might change- will people stop using React Flow to build whiteboard tools as alternative whiteboarding libraries (like tl;draw) gain popularity? Will more engineering-focused apps start using React Flow? Whatever it might be, we still have a lot to learn about each type of tool in the current landscape, which is where user interviews could help us.

How do our users get help when they’re stuck?

Our documentation is split up into three categories, reflected on our website’s header: Learn (guides and tutorials), Reference (API reference), and Examples. We asked participants if there is a category of docs that they use more than others and 48% said they use the API reference the most! On the other hand, only 15% said they use the tutorials the most, and the examples sit somewhere in the middle. When we compare this to how much time participants have spent with the library, it is clear the newcomers spend more time with our long-form guides and more-experienced folks want to jump right into the API reference.

A surprising 26% of folks said they were getting help with React Flow from ChatGPT. This is a little disheartening given the amount of time we spend on our docs, but it’s made us consider whether we can offer something similar directly. We have so much documentation now that something more conversational might be the best way to navigate it!

On the other hand, 90% of respondents said they were using the official documentation! More interestingly, 8 people said they don’t use the docs: for those folks our discord server reigns supreme. Maybe there is something to be said for a more conversational approach to our docs 👀

We forgot to put Github as a multiple-choice answer to this question, but still 6 people wrote it in themselves under “other.” We imagine more people would have mentioned Github if it had been listed with the other options (React Flow Docs, Discord, etc.). The link to the survey was very prominent on our Discord server, which could have influenced the high number of respondents saying they get help through Discord (the 2nd-most selected option).

What are the biggest pain points using React Flow / what features are missing?

We asked two open-ended questions about this, and got a wide variety of answers. It was so wide, coding the data nor affinity mapping was able to give a good overview of what was going on. Instead, what was most helpful here was for us to go through the responses to these questions as a team, finding patterns we saw between answers, and collecting problems.

When asked for difficulties and missing features, four topics were clearly coming up again and again: state management, layouting, performance, and editable “smart” edges. These are all things we were aware were problems, but knowing they are so prominent and common in the community has given us an extra kick to address them somehow this year, and to see if these problems are reduced by the end of next year. We’ve already managed to make progress towards them in the past months with a new editable edge pro example, performance improvements coming in React Flow 12, and computing helpers hopefully make state management easier for some applications.

Performance - limits and best practices

Many folks who try to build React Flow apps with hundreds of nodes have trouble with performance. Although we made some performance improvements at the end of last year with the help of Ivan that will be released in React Flow 12, the library still has some clear performance limits: compared to other libraries, React Flow can render arbitrary react components in the flow, while lots of other libraries render on a canvas. In this way we trade performance for more flexibility, but the survey feedback has helped us recognize that we don’t spell out this performance trade-off anywhere in our documentation, and we should probably do so early, when someone is choosing which is the right tool to use for their project.

On the other hand, there are some common best practices to make more performant React Flow apps, but they come from learned wisdom which is not clearly communicated in our docs. We could do a better job here of communicating the performance limits and best practices of React Flow at the stages where developers are choosing which tool to use for their project.

Custom Nodes & Edges - Feature-full, but hard to grasp

Many folks mentioned custom nodes and edges as a difficult part of using React Flow. They seemed to have a hard time understanding how they work internally, or didn’t have enough guidance on more advanced use cases with custom nodes. It seems like the work we have to do next with custom nodes and edges is to help people understand how they work from the basics and from inside-out, so they can easily get started with them, and then use them in more complex use cases as they move forward with their project.

Explaining our internals better

In both examples of performance and custom nodes and edges, a better onboarding into exactly how the insides of React Flow works might enable users to more easily build their complex projects. Some respondents called out the fact that it was difficult to understand the inner-workings of React Flow, and that made it harder to create what they wanted. This kind of feedback seems to ask for more than just another example, but a guide or tutorial that teaches the concepts behind the library.

Devtools was a solution that some users mentioned- a way to expose exactly what is happening as nodes and edges move around the screen. This might also be a way for folks to learn exactly how React Flow works on the inside by testing things out and seeing what data is changed. As a result of this feedback, we did make our first foray into devtools for React Flow, and we could imagine expanding on this more in the future (maybe we’ll ask about it more directly in a future study).

Layouting - A known, close-to-home problem

We’ve always known that layouting has been a difficult part of using React Flow. Nearly half of respondents said they have done node layouting, so it’s something that needs to be done for so many projects. We’ve had many requests to incorporate a layouting library into the core, but we’ve decided not to and instead to point our users to external libraries like Dagre or Elkjs.

Hearing so many people mention difficulties again with the layouting libraries does tempt us to work on our own layouting library that could be used with React Flow, which would be a big decision for us due to the building and maintenance tasks that would follow. If we don’t choose this path, it would still be worthwhile to do some more handholding of how React Flow users can more easily implement external layouting libraries into their projects. We already do this, but could always do further research to understand where more needs exist in this space for our users.

State Management - React is hard

While layouting is a problem that is closely intertwined with React Flow, state management is a much more general React concept that feels less “close to home.” It was very often mentioned by our users, and we did add computing flows in React Flow 12, which will hopefully make state management easier for some use cases. Besides that, we think it might be best to point our users into the direction of resources that already offer ways to learn the concepts state management, such as general React tutorials or third-party state management libraries like Zustand.

How do our users feel about React Flow Pro?

We found that the most common reason people subscribe to React Flow Pro is for access to the Pro examples. We only got 19 responses to this question in this survey, but this correlates to another survey (with 82 respondents) we did with Pro subscribers where they said the same thing.

A few folks entered a custom answer into the “other” field as their answers as to why they were not subscribed, which included things like:

• “I’m not the one managing budget”
• “I’m not making money from react flow. If I were I would subscribe”
• ”it’s a subscription model”

We rely on a small percentage of our users paying for React Flow Pro, while a majority of our users pay nothing to use our open source libraries and their ecosystem. This is how our business model works, so we know that most people will not be interested in subscribing to Pro at all, or finding it too expensive for them because it does not bring them enough value.

We currently don’t offer regional pricing, so React Flow Pro is a reasonable price for folks in Germany or the US, but we’ve heard from companies in Brazil and India that it is out of their price range, even for companies with 100+ employees. We hope that implementing regional based pricing would reduce the number of people saying they don’t subscribe because it’s too expensive, but we always expect to have a large percentage of users who will never subscribe.

Tips for other maintainers

From all that we’ve learned, we definitely endorse running a survey in your own developer community. It was already valuable for our team to think of “what do we not yet know about our users,” and “what do we want to see change over the next year,” and ask questions to be able to get data about those two things.

Keep the survey short and focused, the attrition rate for these sorts of surveys is high and only gets higher the longer the survey is or the more detail you ask participants to provide. If we had to reduce our survey to just three questions, we would choose:

1. In a few words, describe what you are building with [your project]
2. What has been most difficult for you about using [your project]? (subtext: This can be about the library, docs, ecosystem, or integrating it with other technologies.)
3. Is there a feature you wish [project] had? (subtext: This can be something you wish were built into the core or something outside like an example or helper tool)

Also doing a survey just… feels good? A lot of folks said they like the library and support our work, which is a wonderful motivator.

And if you can, share out the results- even if it’s months later ;)

Get in touch

We’re going to do this again this year for sure, and we’re excited to see if anything has changed since 2023 - hopefully less people will have the same big issues as they reported this time when we change things, excited to be able to compare between years and see what shifted.

Thanks for reading, and if you have any thoughts, questions, or feedback, we’d love to hear from you! Contact us at info@xyflow.com

Cheers and happy researching!

Hayleigh & John