A couple years ago I was looking into doing things at the reconciler level - either to wrap around PIXI or WebGL straight. Did a bunch of tests: https://dakom.github.io/react-renderer-test/
Conclusion I came to is that React itself is the bottleneck - even when you take ReactDOM out of the picture and even if you do nothing in the rendering phase. Ultimately, once you need several thousand entities, you end up with anti-patterns in order to squeeze out better performance, like keeping all your entities in arrays and objects instead of each being its own component.
YMMV and it's a cool idea - don't want to rag on hard work, but thought it might help to give a heads up of the trouble I ran into :)
A gentle request: if you author something like this and you put time into making it so that somebody finding it can learn about it, please also consider explaining what the intent and expected outcome of that project is.
What's unclear is why I should consider it over an alternative, and if indeed the authors think I should. Also, is it an experiment in the sense that it's a learning opportunity for the author, or does somebody think a serious advancement is being made?
Without answering these questions, it's hard or impossible to know in what context I would want to use this.
Now, this doesn't matter for every project, but I say this here since it's clear that effort has been put into making this approachable for somebody with no context.
The more general lesson here is that people don't just want to know what your project is. They also want to know if they should be using it. If you want your project to be used, one of the easiest things you can do is explain what problem your project solves and why somebody with that problem should use your project.
A "hook" is a kind of special function you can call from within a React component to store state, perform side-effects, and so on: https://reactjs.org/docs/hooks-intro.html
This is one of those things where if you have to ask, it's probably not useful for you. If you have used both WebGL and React, it's obvious why this is an interesting experiment.
This is also what bothers me about reading academic papers. Generally, the set of people who both need the introduction and who can make use of the contents of the paper is an empty set.
That's a bit presumptuous. As is my case, you can have real use cases for WebGL and React and have worked with them, yet still want answers to those questions.
There are already a few people here in your set in this case including me; although I am not really fan of the ‘React should power all’ movement (it is quite painful, like [0]) but this can be interesting for a more beginner crowd if it has more details.
There's also react-three-fiber[1], which works through three.js, rather than directly on WebGL. Discussed 2 months ago[2]. Development has been active; 15 contributors. Issue #80 mentions it being used to build Storyboarder's Shot Generator[3] (accessible creation and editing of storyboards, including in VR).
Rendering a single static 3D object lit by one point light isn't much of an achievement these days -- I'd be curious to see how this performs with hundreds/thousands of elements moving around on the screen at once.
My experience with React suggests the answer is "not well." (But I'd be happy to be proven wrong on that point!)
For sure it would be nice to see some stress tests of performance.
From my experience with React, if it's used properly so that the entire component tree isn't rendered every frame, I would expect the overhead of using to be almost nil. You can see in the examples the author using React.memo for this.
Sure, but you can't really avoid rerendering every frame with OpenGL.
(Not without a lot of tricky caching, at least, which has it's own costs).
Not saying this is impractical (Personally, I wouldn't bet on it, but I'm sure it's fine for some things), so much as that the cost model here is fundamentally different.
Regarding React: In many webgl use-cases UI-framework overhead can be neglected as the user interacts either with the scene or the UI rendered by the framework. The browser doesn't usually need to update the DOM and the scene in one frame.
I think the question here is how well React Hooks and their reconciliation perform "at scale". What may not be a problem with a couple of 2D UI elements may turn into a disaster in a non-trivial 3D scene.
Conclusion I came to is that React itself is the bottleneck - even when you take ReactDOM out of the picture and even if you do nothing in the rendering phase. Ultimately, once you need several thousand entities, you end up with anti-patterns in order to squeeze out better performance, like keeping all your entities in arrays and objects instead of each being its own component.
YMMV and it's a cool idea - don't want to rag on hard work, but thought it might help to give a heads up of the trouble I ran into :)