Background:
I’m a fulltime webdev for my dayjob who has been looking for a side project to get passionate about. I was really inspired by https://hordes.io/ , an online game built right into a website, even though that’s not built with three.js, but instead is built with OGL (but originally was prototyped with three.js, but not the point).
Anyway, lately I’ve been working on a React/Node app that acts as the “wrapper” for the game, IE has a shop with stripe integration (for future monitization), account pages, etc. It uses redux, chakra UI, node, express.
My plan was to add another page in my hierarchy that is just the game window. I was curious if there’s any reason I should invest in Three.js over R3F, given that I’m using React? Keeping in mind that I expect the scope of the game to increase over time (ie a larger project).
I saw a thread about using standalone Three.js in a React app, but most of the replies were basically “Why?” but wanted to see if it would apply to my case as well where I intend to use 3js quite heavily.
When writing a project similar to hordes you’ll inevitably hit a performance wall which you’ll only be able to solve by writing custom code with vanilla three, and then even more extreme cases which can only be solved by custom shaders. R3F is good for simple things, and structuring your code well and in a super predictable way- but anything more complex in terms of performance, you’ll need experience with vanilla as well.
there wouldn’t be any reason not to use it. react-three-fiber is threejs, optionally with declarative semantics. react helps you to re-use and share code, make projects scalable. it gives you an eco system. you will write less code, you can outperform vanilla quite easily because you have drop in optimisations.
the best thing you could do is to evaluate it yourself. go through some of the demos in the documentation. imagine you had to remake one in vanilla, ask yourself how much the effort would be in comparison.
another resource for evaluation is bruno simons threejs journey the first half is vanilla, the second react-three-fiber. he starts with re-doing the same projects, which are now a fraction of the code used before. in the intro lesson he discusses the outline of the react part, and what impact react makes.
ps, i just saw this
It uses redux, chakra UI, node, express.
you are already using react. fiber, like react-dom is a renderer, not a wrapper or binding. react-dom renders divs and spans, fiber renders meshes and materials. react was made for that purpose. if you use react and imperative three you have a black box without integration. it would be as if suddenly one half of your app used imperative dom, querySelector and appendChild.
This is the kinda thing I was interested in seeing if folks had insight into. Admittedly I don’t know fully what I’m getting myself into, and I’m going for more of a 2d plane with 3d rendering (2.5d) which may be less performance heavy that hordes, but nonetheless I figured hordes is not at all a “standard use case” for something as heavy as hordes.
In this case, your recommendation would be just to use vanilla threejs in my react project (from the get-go)?
Hmmm I really appreciate this insight, and that’s how I felt initially as well. But in another comment (from someone I’ve seen in the forums quite frequently) they mention hitting performance walls with R3F in the scope of a project as big as something like hordes. Unfortunately I don’t have the experience to know what those walls would be, since again the R3F documentation explicitly mentions there’s no overhead.
Regardless the project I’m embarking on was meant to be done as a passion project that would involve lots of learning, which it certainly is in my case since I don’t know how to answer these questions. But I did get the vibe that if using React (for the surrounding website) then I might as well use R3F (for the game within the website) as well.
Tbh my point was to try and answer the question of “[is there] any reason I should invest in Three.js over R3F [?]”. In case of your project I’d still personally go with R3F, especially that the rest of your code is already react.
Just keep in mind that for gaming things like - off the top of my head - positioning, most of networking, world streaming, physics¹, and pretty anything else that is real-time, you’ll still need vanilla three.js - either in useFrames or custom imperative helpers.
(Another important thing to take into account is the server-side. Sometimes it’s useful to run things on the server-side and are broadcasted to players. A tiny advantage of vanilla three.js over r3f is that the same code / parts of the same code can be very easily run on the server-side, without all the mounting / unmounting shenanigans that come with react. It’s doable with r3f but a little bit more complex.)
¹ - r3f does give you a good physics support with rapier, but it’s not going to be viable for multiplayer out of the box
Hey thanks for giving input again, this does help clarify some things for me. First off, the majority of my game logic will need to be performed server-side via websockets, as I’m definitely going for a server-authoritative approach. Even considering going with a server-sided physics with something like cannon-es (something like here: https://ballgame.sbcode.net/ ) . World streaming should be a bit easier as I’m going to make distinct, smaller maps with portals between them, as opposed to hordes’ open world approach.
To be honest, I don’t think the surrounding website and the game scene really need to communicate much at all. I provide a way for users to create accounts in my react app, and have an integration with stripe+a web shop if I someday wanted to monetize. Other than that the react app probably only needs to communicate whether a player is authenticated or not to the threejs scene.
Basically what I mean to say is, I’m not inherently opposed to decoupling the game from the actual surrounding website, in the case of a more vanilla three approach.
