3 ms·

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. [

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. [1] https://threejs.org/ https://threejs.org/

jasonjmcghee 1y ago
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.
- eyelidlessness 1y ago
  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.
  - mikebelanger 1y ago
    > 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
ttfkam 1y ago
Exactly, as seen with Threlte as a counterpoint. https://threlte.xyz/ https://threlte.xyz/
throwaway314155 1y ago
That all seemed fairly obvious to me.

jasonjmcghee 1y ago

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.

eyelidlessness 1y ago
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.
- mikebelanger 1y ago
  > 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

ttfkam 1y ago

Exactly, as seen with Threlte as a counterpoint. https://threlte.xyz/ https://threlte.xyz/

throwaway314155 1y ago

That all seemed fairly obvious to me.