
React VR: Building Virtual Reality Experiences on the Web - lacker
https://code.facebook.com/posts/215238872297197
======
immediatedelay
Andrew from React VR here. We've been gathering developer input for months as
we tweaked APIs and prepared for a 1.0 release, and now we're excited to open
up things to the broader community for contribution:
[https://github.com/facebook/react-vr](https://github.com/facebook/react-vr)

~~~
jbreckmckye
I'll ask the obvious question: why should I use this when A-Frame already
exists and has the momentum?

~~~
immediatedelay
Very similar to asking why you should use React when Angular came first.
A-Frame and React VR represent different styles, and they both excel at
different scenarios. If you're building a relatively static scene, or really
like the idea of having a small amount of HTML with super powers, then run
with A-Frame. I think it's a fantastic product.

If you know React, find React's declarative style of programming desirable, or
have a more complex, stateful application, then React VR is your best bet.
It's true that the A-Frame community is larger than the React VR community,
and there's more code out there for it, but React VR integrates with the
entire history of React tooling and libraries – React VR doesn't need a
specific data management or navigation library, because it's just React. Our
goal is to take all web developers who know React and enable them to become VR
developers as well.

~~~
jbreckmckye
> A-Frame and React VR represent different styles

They both use HTML-like markup to declare scene graphs. I think the only
difference is that procedural content is easier to generate with React VR. But
then again, if I need to generate objects programmatically, why not just use
Three.js directly? It's a very easy library to use.

> React VR integrates with the entire history of React tooling and libraries

That doesn't strike me as a good thing. Once developers start writing VR
scenes in React, it's only a matter of time before they pull in abstractions
like Redux. This means using a state library to drive React to drive Three.js
to drive WebGL. This seems unnecessary and inefficient in an environment where
framerate is king (because as I'm sure you know, dropping frames in VR causes
motion sickness).

Given ReactVR is just a thin wrapper over Three, I think most developers would
be better equipped just to learn that. They're going to have to at some point,
because last I looked ReactVR had a pretty limited set of inbuilt entities.

> Our goal is to take all web developers who know React and enable them to
> become VR developers as well.

My goal is to remind JavaScript developers that there is a world outside
React, just like there was a world outside Angular and even jQuery before
that. I believe the sooner they engage with the fundaments and free themselves
of proprietary abstractions the more powerful they become.

To that end, I think the React monoculture is holding us back, and perhaps
that's why I have mixed feelings about your project.

