It's great... except that it turns out to be a performance pitfall if the state needs to be frequently updated. The React Three Fiber docs mention this here:
To fix this, they suggest using useRef and manually updating the object. But then your code ends up just as complicated, if not more so, than if you had just stuck with vanilla three.js.
Yeah, I can only imagine what removing an element from the middle of a thousand-element array of entities would do. This has always been a performance weak point for React, but React trees aren’t typically rebuilt from the root 60 times a second. With this, they are.
Sadly I’ve lost the URL but there was once a great comparison of Svelte vs React for this exact functionality. The performance was orders of magnitude better IIRC.
React code looks great, the dev experience is fantastic. But user experience sometimes less so. Hooks kind of hide what’s going on.
I am exploring this area in a pet project, because some part of me has always been absolutely confident that we can do better than both vdom and custom compilers. So far, I have made really exciting progress, though it has never been more than 2-3 levels deep, for example a basic todo list, so it's hard to say that it will solve the main difficulty elegantly, but so far it seems to do so in principle, and I hope soon to come up with a use-case that allows me to finally create the deepRef function that I can just tell is the final piece of the puzzle.
Minor nit, because this is one of my weird special interests: this (being render-agnostic) isn’t necessarily a property of React’s virtual DOM. It’s a property of JSX being explicitly specified without semantics.
For instance, Solid also supports custom JSX renderer, but doesn’t use a VDOM to achieve that.
I find it helpful to think of JSX as analogous to a macro (in the lispy sense of the term), except that its syntax and implementation are decoupled. Most compiler tooling assumes the implementation maps to a function call, but even that isn’t strictly required (and again, Solid is a counter example).
JSX gets compiled to a tree of function calls, but the hard part is done using react (or solid, or svelte, or ...) to hook in to the lifecycle of nodes in that tree.
Something I wish is that you could "render" JSX agnostically and just get a JSON data structure describing a tree of tags, which is not specific to the platform or even the framework, and then you could pass that off to whichever subsystem for whichever purpose (or even serialize it or send it over a wire). We wouldn't need separate build plugins for each JSX-using framework, you'd just pass them your data
Hello! One of the main challenges of figuring a JSX syntax out is what to do about the “children” prop.
Experientially, typescript still has a bit of trouble figuring out the right types for these nested structures. Even with a typed jsx function it sometimes doesn’t infer correctly, so providing plugin capability would take a very careful hand
Right, but only with a custom transpilation step. It would be nice if there were only a single standard JSX transpilation that all the frameworks and platforms ingested the output of
It kinda is! The only difference between JSX transpiler outputs is the factory function (and the Fragment component). For React the factory function it's `React.createElement`, for Preact it's `h`.
Babel has a pragma property, and esbuild allows you to pass it in the command line: `--jsx-factory=h`.
The point is about the declarative abstraction and how it's useful for people who don't know what "React Three" might entail, not to enumerate all the frameworks that have it under a submission about "React Three Ecosystem".
Yeh that seems problematic because you no longer have access to the render loop, you are letting React manage your render loop which seems kinda problematic for a game where you want very granular control over what happens each iteration, fps, etc.
This imperative/declarative shift happened as part of UIKit -> SwiftUI too. However, it’s still pretty well accepted that if you’re doing anything “complicated” you’re going to end up writing UIKit imperative code.
I wonder if there’s any research (PL or maybe even more philosophical) on whether declarative approaches can logically cover all imperative use cases.
Basically: is there something special about “verbs” (imperative) that let you do things that “nouns” (declarative) cannot, at least within reasonable verbosity constraints?
Yeah, one of the qualities of the abstraction is how often you have to reach for the escape hatch, how nice it is to use the escape hatch, and whether it's an escape hatch vs. just two clean modes of tooling working together.
SwiftUI has failed pretty much all of those for me.
In react-pixi / react-three, you have your declarative component tree alongside a `useTick`/`useFrame` function that you can use to do more surgical work, and it works well together. Each component can tap into the tick to update itself.
I've migrated a few medium-sized pixi/three projects to their React wrappers, and the code cleaned up so well that I could work on them again.
Before that, I'd tried modeling games in Elm and then using its port system to send the game state to JS which then updates the pixi/three world. But it's exactly this updateWorld(oldWorld, newState) that's hard to write, yet that's what these libs do for you.
Well, you can interpret the program's text as a declarative (and completely static) approach to describe what will happen at runtime.
But you can actually see this dichotomy in template libraries, they usually have constructs making them fully Turing-complete (loops, conditionals, etc).
This declarative system often is less intuitive once you get into the nitty gritty of things imo. Showing the hello world most basic example proves nothing
It's worse IMO. In a real three.js example, to repo their example, you'd make one BoxGeometry and 2 Mesh(es) But that wouldn't be idomatic React so they don't show it.
Are there any guides on using the "react style" framework (JSX / State) to generate outputs other than DOM? I've been interested in the idea of doing something similar for JSON or markdown document generation.
note three.js [1] has nothing to do with React out of the box though, this page highlights an atypical way of using three.js through a popular React binding.
You might be getting downvoted for saying it's an "atypical" way of using three.js. the pmnd.rs community (for example) is quite large.
I understand why people like the declarative nature of react three fiber, but it's quite unfortunate that it requires something like code sandbox to allow modification / working with it on the web- but that's by nature due to being react.
Vanilla three.js can be written surprisingly similarly, if you are disciplined about breaking things up into functions/components. And no react necessary / can embed a code editor and allow direct modification.
For what it’s worth, this is also true of whatever else one might express with JSX: imperative code (and syntax, and semantics) can be structured in a way that closely resembles declarative code… with discipline.
It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction.
> It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction.
That's one of the stronger arguments for opinionated pre-processors/frameworks/libraries like Typescript/TSX/JSX/React in general. Because it abstract away those things that only some team members would embrace, you effectively make everyone embrace them. That leads to less friction.
But this reduced friction comes at a cost: more complex abstractions and incidental bugs related to that complexity. And as far as the procedural vs declarative: after a certain degree of complexity, I find myself introducing procedural codes within useEffects, useMemos anyways
been there - love how clean react-three looks at first but man, once you hit real perf walls, its like, why am i even using this lol. you think the push for these declarative libs is just for quicker onboarding or something deeper?
I tried to build a game with react expo and react three last year and it was painful to me.
There were version mismatches and some features didn't work if I combined them in some ways that I needed sooner or later when trying to finish a project.
I believe it is correlated with the fact I tried this on mobile, but maybe someone else has made the same experience with it.
At this point I start to evaluate technologies end to end to not be surprised when projects break at a certain level of maturity or in size when they get close to release in terms of feature completeness.
Yeah, they went all in on Codesandbox early on, and at the time that was a good idea.
But very soon after Codesandbox made the switch to containers and started chasing monetization. I saw an interaction between the creators of each on Twitter at the time where Codesandbox promised not to throttle or limit R3Fs examples. But I don't think they fully kept that promise.
Changing priorities I guess. I forget the name of the guy who originally created R3F but he is really skilled at making beautiful examples. I think he's much less involved now - the people I see responding to PMNDRS GitHub issues these days are focused on the technical stuff rather than docs and examples.
I'm guessing that Safari on iOS doesn't support any of the necessary webgl here? Every example shows up with a blank component with a question mark emoji at the center.
I start using X3D at work in order to enable some cool functionality showing steps to build an assembly in 3D, and it's actually insane how high the performance is. It's all HTML components, so I wrote a super thin React wrapper (essentially the scene needs to be manually loaded once, that's about all) and have been cruising with that.
Effortless to fly, rotate, hide or highlight parts, decompose things into x3d assets, and so on.
It might have issues somewhere, I haven't widely tested browser compat or anything, but it's curious to me how little I see it versus how much I see ThreeJS when it seems that X3D is the more capable platform.
Since they bring their own reconcile(a, b, diff) function to React, these libs can turn:
Into: In other words, you write declarative code, and it does the hard imperative work of adding/removing/disposing/updating things for you.Just like how it helps you sync your data model to underlying stateful DOM nodes; the idea can be applied on top of any stateful system.
https://r3f.docs.pmnd.rs/advanced/pitfalls#avoid-setstate-in...
To fix this, they suggest using useRef and manually updating the object. But then your code ends up just as complicated, if not more so, than if you had just stuck with vanilla three.js.
React code looks great, the dev experience is fantastic. But user experience sometimes less so. Hooks kind of hide what’s going on.
State should basically only be used as "keyframes"
For instance, Solid also supports custom JSX renderer, but doesn’t use a VDOM to achieve that.
I find it helpful to think of JSX as analogous to a macro (in the lispy sense of the term), except that its syntax and implementation are decoupled. Most compiler tooling assumes the implementation maps to a function call, but even that isn’t strictly required (and again, Solid is a counter example).
Experientially, typescript still has a bit of trouble figuring out the right types for these nested structures. Even with a typed jsx function it sometimes doesn’t infer correctly, so providing plugin capability would take a very careful hand
Babel has a pragma property, and esbuild allows you to pass it in the command line: `--jsx-factory=h`.
https://esbuild.github.io/content-types/#auto-import-for-jsx
https://threlte.xyz/
When all you know is React, everything gets viewed through that limited lens.
The point is about the declarative abstraction and how it's useful for people who don't know what "React Three" might entail, not to enumerate all the frameworks that have it under a submission about "React Three Ecosystem".
I wonder if there’s any research (PL or maybe even more philosophical) on whether declarative approaches can logically cover all imperative use cases.
Basically: is there something special about “verbs” (imperative) that let you do things that “nouns” (declarative) cannot, at least within reasonable verbosity constraints?
SwiftUI has failed pretty much all of those for me.
In react-pixi / react-three, you have your declarative component tree alongside a `useTick`/`useFrame` function that you can use to do more surgical work, and it works well together. Each component can tap into the tick to update itself.
I've migrated a few medium-sized pixi/three projects to their React wrappers, and the code cleaned up so well that I could work on them again.Before that, I'd tried modeling games in Elm and then using its port system to send the game state to JS which then updates the pixi/three world. But it's exactly this updateWorld(oldWorld, newState) that's hard to write, yet that's what these libs do for you.
But you can actually see this dichotomy in template libraries, they usually have constructs making them fully Turing-complete (loops, conditionals, etc).
If the only tool you have is React everything around you start looking remarkably similar to JSX.
https://www.npmjs.com/package/react-reconciler
https://github.com/levicape/fourtwo
The best way to use template JSX is either with a CLI, or by using #! pragma to output the constructed yaml after using a builder.
[1] https://threejs.org/
https://threlte.xyz/
I understand why people like the declarative nature of react three fiber, but it's quite unfortunate that it requires something like code sandbox to allow modification / working with it on the web- but that's by nature due to being react.
Vanilla three.js can be written surprisingly similarly, if you are disciplined about breaking things up into functions/components. And no react necessary / can embed a code editor and allow direct modification.
It’s doesn’t have to be especially onerous discipline if you embrace it, but it becomes considerably more onerous as it becomes more social: if some members of a team/contributors to a project embrace it more/less than others, that difference in commitment becomes a constant source of friction.
That's one of the stronger arguments for opinionated pre-processors/frameworks/libraries like Typescript/TSX/JSX/React in general. Because it abstract away those things that only some team members would embrace, you effectively make everyone embrace them. That leads to less friction.
But this reduced friction comes at a cost: more complex abstractions and incidental bugs related to that complexity. And as far as the procedural vs declarative: after a certain degree of complexity, I find myself introducing procedural codes within useEffects, useMemos anyways
https://r3f.docs.pmnd.rs/getting-started/examples
The examples here
https://threejs.org/examples/#webgl_animation_keyframes
seem to work great on my phone...
But very soon after Codesandbox made the switch to containers and started chasing monetization. I saw an interaction between the creators of each on Twitter at the time where Codesandbox promised not to throttle or limit R3Fs examples. But I don't think they fully kept that promise.
All the broken ones I saw were weird things like model/asset files just not being there at all.
I found Threlte[1] recently and enjoy not having to write low-level Three.js code to make things happen.
---
[1]: https://threlte.xyz
It uses a virtual DOM to diff the desired state and the current one: https://shopify.github.io/react-native-skia/docs/canvas/cont...
If you're interested how it's implemented, that's the source code: https://github.com/Shopify/react-native-skia/blob/main/packa...
Taking a quick look at [the docs](https://r3f.docs.pmnd.rs/getting-started/introduction) linked above, I see the use of Canvas. Fair enough.
I start using X3D at work in order to enable some cool functionality showing steps to build an assembly in 3D, and it's actually insane how high the performance is. It's all HTML components, so I wrote a super thin React wrapper (essentially the scene needs to be manually loaded once, that's about all) and have been cruising with that.
Effortless to fly, rotate, hide or highlight parts, decompose things into x3d assets, and so on.
It might have issues somewhere, I haven't widely tested browser compat or anything, but it's curious to me how little I see it versus how much I see ThreeJS when it seems that X3D is the more capable platform.
GP - are we misunderstanding something here?