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.
eyelidlessness · 34m ago
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).
hombre_fatal · 6m ago
I see. I'm not sure how much is React-specific in the impl, never really looked.
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?
banalico · 11m ago
I think there are declarative languages that are Turning-complete, like Prolog, etc. So declarative approaches should be equally good.
eyelidlessness · 28m ago
A (the?) major area where this is generally considered unanswered, and active in PL research, is “effects” (as in, side-effects).
nicce · 30m ago
Aren’t declarative approaches just abstractions over imperative? Somehow you need to get there. (Processor executes instructions, in the end)
cjonas · 1h ago
Just to clarify, you'd write the bottom code (declarative) and the library translates it to the above (imperative) code?
MortyWaves · 1h ago
That’s right
cjonas · 1h ago
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.
cwackerfuss · 1h ago
I don't have a good guide for you, but this is the lib you use to create custom React renderers:
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.
eyelidlessness · 21m 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.
talkingtab · 2h ago
When I was new to the integration of threejs and react I found these examples to be just amazing.
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.
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).
Here's a three.js lib for Solid: https://github.com/solidjs-community/solid-three (unmaintained)
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?
https://www.npmjs.com/package/react-reconciler
[1] https://threejs.org/
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.
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...