3 ms·

Question for those who've done both web and game dev: am I right in thinking that jQuery's like ECS, and React is more like (what the article calls) "parent, pa

by yoz 3y ago

Question for those who've done both web and game dev: am I right in thinking that jQuery's like ECS, and React is more like (what the article calls) "parent, parent, parent"? Context: I'm an aged web dev with very little game dev experience, and I did less frontend after React appeared. In my limited experiences with React, it's much more about declaring React components (not ECS components) in terms of other components, so it's structure based rather than attribute based. Whereas jQuery feels more like ECS, since code mostly spends its time querying across the DOM and attaching behaviours to objects (nodes) based on attributes. Obviously I'm massively generalising here, and web apps tend to behave very differently to games. But it does explain a little about why jQuery feels more adaptable as a web app grows.

deleted 3y ago
[deleted]
__s 3y ago
What you're noticing is jQuery is more about querying dom & manipulating it based on those queries as opposed to composing vdom/state React apps work as you'd like when you put shared state in something like redux & then components query state
JoeOfTexas 3y ago
No, a React component is not tied to any one parent component. The paradigm is entirely of its own kind. It may react to parent data, or it may react to external data. It's purely a rendering tree management system. There are no rules on how to manage the logic flow.
SeanAnderson 3y ago
I can see what you're getting at and sure, I think there are some parallels. I think the parallels grow stronger if you force your jQuery queries to always be composable. So, no $('.js-fooSubmittButton') but yes $('.submit .clickable .highlightable'). You'd then end up writing generic functions which work against a set of entities returned by intentionally generic queries. Bevy is still declarative in some ways, though. You create a Sprite, but you don't have to worry about the Sprite's rendering process/lifetime. You just spawn/despawn/update its properties. There's an entire "render world" which is managed by Bevy and is distinct from your app's world. In this way, you're still working through a layer of abstraction prior to rendering, like React, rather than manipulating the DOM directly, and you reap performance benefits by leveraging this abstraction.
btown 3y ago
Just like jQuery can lend itself to spaghetti code, but can also be a basis for scalable web apps (I have fond memories of the Backbone.js era!)... React can lend itself to a strong coupling between hierarchy and state management, and that's what many projects using "just React" will gravitate towards. But it's also possible to separate those concerns in the React ecosystem. If you look at systems like React Redux, and the general pattern of a central store to which different pieces of code can subscribe to, it's perhaps the thing that is closest to ECS on the frontend. See https://redux.js.org/understanding/thinking-in-redux/three-principles https://redux.js.org/understanding/thinking-in-redux/three-p... and the examples at: https://react-redux.js.org/api/hooks#useselector-examples https://react-redux.js.org/api/hooks#useselector-examples Rather than drilling state through hierarchical props, one can create a specification for a TodoListItem that has it subscribe to the "todos" part of storage, and rerender when that changes. And then you have a separate "system" (using the word both figuratively and in the ECS way!) that responds to UI input or network traffic, updates some isolated global state that only that system controls (say, the "todos"), and notifies all entities that are subscribed to the derived state. So then, a React functional component that religiously uses Redux (or a similar external storage system) for state management becomes akin to an ECS-entity whose set of ECS-components corresponds to which Redux useSelector and useDispatch hooks it chooses to use. And the ECS-systems are what mutate state in response to dispatched actions - you just need to make sure they have good boundaries. If you adhere to this, the parent-child relationship between components really doesn't matter; you could nest a TodoListItem just about anywhere and it would behave the same. It's just that in web dev it's so common to say "I am the box for an ordered list of things, and as I move and reshape my children should do the same" that while you could in theory have an ECS system that track hierarchies and repositions children using JS as the parent moves, it's more natural to do something a bit more hybrid and allow the natural DOM hierarchy to control certain things - but not all.

by yoz 3y ago

deleted 3y ago

[deleted]

__s 3y ago

What you're noticing is jQuery is more about querying dom & manipulating it based on those queries as opposed to composing vdom/state React apps work as you'd like when you put shared state in something like redux & then components query state

JoeOfTexas 3y ago

No, a React component is not tied to any one parent component. The paradigm is entirely of its own kind. It may react to parent data, or it may react to external data. It's purely a rendering tree management system. There are no rules on how to manage the logic flow.

SeanAnderson 3y ago

I can see what you're getting at and sure, I think there are some parallels. I think the parallels grow stronger if you force your jQuery queries to always be composable. So, no $('.js-fooSubmittButton') but yes $('.submit .clickable .highlightable'). You'd then end up writing generic functions which work against a set of entities returned by intentionally generic queries. Bevy is still declarative in some ways, though. You create a Sprite, but you don't have to worry about the Sprite's rendering process/lifetime. You just spawn/despawn/update its properties. There's an entire "render world" which is managed by Bevy and is distinct from your app's world. In this way, you're still working through a layer of abstraction prior to rendering, like React, rather than manipulating the DOM directly, and you reap performance benefits by leveraging this abstraction.

btown 3y ago

Just like jQuery can lend itself to spaghetti code, but can also be a basis for scalable web apps (I have fond memories of the Backbone.js era!)... React can lend itself to a strong coupling between hierarchy and state management, and that's what many projects using "just React" will gravitate towards. But it's also possible to separate those concerns in the React ecosystem. If you look at systems like React Redux, and the general pattern of a central store to which different pieces of code can subscribe to, it's perhaps the thing that is closest to ECS on the frontend. See https://redux.js.org/understanding/thinking-in-redux/three-principles https://redux.js.org/understanding/thinking-in-redux/three-p... and the examples at: https://react-redux.js.org/api/hooks#useselector-examples https://react-redux.js.org/api/hooks#useselector-examples Rather than drilling state through hierarchical props, one can create a specification for a TodoListItem that has it subscribe to the "todos" part of storage, and rerender when that changes. And then you have a separate "system" (using the word both figuratively and in the ECS way!) that responds to UI input or network traffic, updates some isolated global state that only that system controls (say, the "todos"), and notifies all entities that are subscribed to the derived state. So then, a React functional component that religiously uses Redux (or a similar external storage system) for state management becomes akin to an ECS-entity whose set of ECS-components corresponds to which Redux useSelector and useDispatch hooks it chooses to use. And the ECS-systems are what mutate state in response to dispatched actions - you just need to make sure they have good boundaries. If you adhere to this, the parent-child relationship between components really doesn't matter; you could nest a TodoListItem just about anywhere and it would behave the same. It's just that in web dev it's so common to say "I am the box for an ordered list of things, and as I move and reshape my children should do the same" that while you could in theory have an ECS system that track hierarchies and repositions children using JS as the parent moves, it's more natural to do something a bit more hybrid and allow the natural DOM hierarchy to control certain things - but not all.