React is very challenging to use with game development, and probably not worth it. This blog post doesn't get into the reasons you would actually want to choose React for gamedev, so there's nothing to refute. But before you choose React, consider:
- React is fundamentally inappropriate for a 60fps game, both because of the need for re-creating immutable data every frame causing a lot more GC, which will slow down your game, and because the component render process is always slower than imperative mutation. So you have to bail out of React, and forego immutability, to get performance. Both react-three-fiber and react-spring sidestep React rendering entirely to get 60fps!
- Think about what goes into a game. The content is probably 100% dynamic. Making a React component is easy when you're hard coding the contents, or have limited branching (like if the user is logged in). In a game, displaying components is purely dynamic based on state. So you'll need one or more components that do something like
and React clearly offers no benefit here. For the record, most react-three-fiber demos are static scenes with hard coded components. If you want an actually fully dynamic game, based on the output of a level editor, you're going to be in trouble. And god help you if you need to consider building a level editor as well! Building a level editor and asset pipeline will take up 90% of your efforts, you'll build a bad one, and give up eventually.
I don't disagree with your points. However, using React for making the UI portion of your game is still using React for game dev. The default would have been to just make your UI within the canvas itself.
Now in the post, I explained that considering option 1) Using React for the game rendering vs 2) Using React only for the UI, I went with 2) and explained why.
However, I want to thank you for explaining why React is unsuitable for rendering the game itself.
I didn't find this article especially compelling. It basically says, "Don't use React for the game dev specific aspects of development. Instead, use it for the UI since that's what React excels at."
I don't find that to be especially insightful because there's clear parity between a game's UI and a website. In contrast, the actual game rendering logic has the potential to ask far more of React than it's capable of giving.
A couple of years ago I tried building a 2D ant colony sim using React+PixiJS. (https://github.com/MeoMix/antfarm) It didn't go great because React's reconciler became a performance bottleneck very quickly, even with everything memoized, and the GC caused stuttering which was difficult to mitigate when React wants to work with immutable objects rather than mutating existing state. The latter is easy enough to work around, but trying to avoid instantiating strings, etc. just felt like I was working against my tools a bit.
That said, new versions of React and PixiJS have come out since I last tried and it's possible that those performance enhancements + subdividing my grid and doing smarter updates would allow me to continue on for a while, but, at the time, I didn't feel like I was getting the dev experience I wanted out of React for a canvas-driven simulation.
All that said, I absolutely find the idea of declarative, reactive game development quite appealing and if your game doesn't ask much of performance then the trade-offs for getting that could very well be worth it.
To be clear, the entire video is adding a textbox overlay to a non-React game. The actual game is not driven by React at all, it's driven by "kaplay" as you can see imported here: https://github.com/JSLegendDev/react-kaplay/blob/5ee7d69ac86... and all the sprites and controls are set up independent of React https://github.com/JSLegendDev/react-kaplay/blob/5ee7d69ac86...
React is very challenging to use with game development, and probably not worth it. This blog post doesn't get into the reasons you would actually want to choose React for gamedev, so there's nothing to refute. But before you choose React, consider:
- React is fundamentally inappropriate for a 60fps game, both because of the need for re-creating immutable data every frame causing a lot more GC, which will slow down your game, and because the component render process is always slower than imperative mutation. So you have to bail out of React, and forego immutability, to get performance. Both react-three-fiber and react-spring sidestep React rendering entirely to get 60fps!
- Think about what goes into a game. The content is probably 100% dynamic. Making a React component is easy when you're hard coding the contents, or have limited branching (like if the user is logged in). In a game, displaying components is purely dynamic based on state. So you'll need one or more components that do something like
and React clearly offers no benefit here. For the record, most react-three-fiber demos are static scenes with hard coded components. If you want an actually fully dynamic game, based on the output of a level editor, you're going to be in trouble. And god help you if you need to consider building a level editor as well! Building a level editor and asset pipeline will take up 90% of your efforts, you'll build a bad one, and give up eventually.