I actually went on this whirlwind adventure where I used JSX to create custom vanilla objects so I can work with it like a hierarchy... I think I wrote about that somewhat here in a different thread, but some relevant code:
JSX tree: https://github.com/DriftJS/drift-example-state-scenegraph/blob/master/src/app/state/State.tsx#L25
Updating it with lenses: https://github.com/DriftJS/drift-example-state-scenegraph/blob/master/src/app/App-Main.ts
Crawling it: https://github.com/DriftJS/drift-utils/blob/master/src/lib/state/State-Tree-Mapper.ts#L45
Conclusion? Really cool technique for small apps and for the sake of learning - but I started building something bigger and it got weird (needing to store ephemeral indexes in the state tree, and needing to make lenses for everything and store those in the state, etc.)
Not saying it's exactly what you're talking about - just that I went pretty deep down a related rabbit hole along that direction
I hear that. I think React offers some convenience and community-contributions that can be a timesaver, and the fact that they focus specifically on DOM stuff with ReactDOM is super efficient - but a clever sodium architecture can probably do everything React itself does in a dozen or so lines, and then it's all about the UI optimizations that can be adjusted more directly when you're focused on something specific.
I'm going to keep going with this approach of Sodium core + React UI, where they communicate via Sodium streams - but I'm not sure if that's the right approach for every project and I'll know more as I go down this road