
Hooks-Based WebGL Library for React - alex_2019
https://github.com/sghall/react-vertex
======
dakom
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/](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 :)

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

~~~
gridlockd
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.

~~~
JasonSage
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.

------
mncharity
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).

[1] [https://github.com/drcmda/react-three-
fiber](https://github.com/drcmda/react-three-fiber) [2]
[https://news.ycombinator.com/item?id=19363595](https://news.ycombinator.com/item?id=19363595)
[3]
[https://www.youtube.com/watch?v=70RNZHEc39Q&t=35](https://www.youtube.com/watch?v=70RNZHEc39Q&t=35)

------
csande17
The ease-of-use of OpenGL meets the performance of React.

~~~
gunn
Performance looks good: [https://react-vertex.com/demo-attenuated-
light/](https://react-vertex.com/demo-attenuated-light/)

Ease-of-use looks good: [https://github.com/sghall/react-
vertex/blob/master/demos/Att...](https://github.com/sghall/react-
vertex/blob/master/demos/AttenuatedLight/Scene.js)

Looks excellent actually.

~~~
csande17
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!)

~~~
gunn
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.

~~~
yoklov
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.

~~~
gunn
The WebGL view might rerender every frame, the react component tree doesn't
have to.

