Introducing the React VR Pre-Release
developer.oculus.comCompare and contrast: https://aframe.io/
A-frame has got a certain amount of traction, it's component based and declarative. It feels like an extensible "VR HTML" (or "VR Web components"). React is similarly component based - but one step removed from the markup.
Hi! I work on A-Frame. The biggest difference for now is that A-Frame is ECS-based (entity-component-system) which promotes composability versus inheritance, similar to the way Unity is set up. A bit confusing since the meaning of component in "ECS" vs. component in "Web Component" or "React Component" are fairly opposite.
A-Frame works with React as well, https://github.com/ngokevin/aframe-react ... but I hope that React VR will attract more web developers to the WebVR community! Good to have more friends in the framework space.
I don't understand the intent here. What am I building that's a browser VR experience? That's as foreign to me as saying a browser cooking experience. Those are words, but I just don't understand how they'd operate together in a way that would be enjoyable and easy to use.
VR videos, VR videogames, VR [insert other here].
Being able to watch a 360 degree video in the browser. Optionally hit a button and put on a headset and use head tracking to look instead of click+drag.
Playing VR games using something like daydream, oculus, etc... All within the browser.
The idea being it keeps the same cross-platform, cross-device, cross-"viewer" (VR headset, phone screen, computer screen, KB+mouse, touchscreen, etc...) that the web is built on.
You probably won't be making the next AAA title in the browser just yet, but it's more than capable of games, videos, and other VR "experiences".
It's a virtual reality experience that runs in the browser. These experiences can be anything: games, tools, entertainment. Mostly anything that a native VR experience can provide (given the limits of Web APIs).
The benefit to having this content in the Web are:
- Open ecosystem
- No gatekeepers or app stores
- No downloads / installs
- Link traversal (hop from one VR experience to another without having to change "apps")
- Instant publish (throw up a site without a review process)
- Instant sharing (Tweet a link to a VR site)
- More accessible for content creators or web developers (HTML, JS)
- Larger audience: no one is going to download a VR app for your small store, but they would more likely click a link on a web page to open it
- Easier to do cross-platform content
Currently there's dozens if not hundreds of VR experiences, apps, games etc but they all live in silos. You launch an exe or whatever then you're done.
It's as if every website needed a downloadable exe and there were no such things as hyperlinks between websites.
WebVR opens up the possibility of navigating between apps, building sites that curate or embed apps - all the richness that distinguishes the web from silo'ed apps.
VR really suits the idea of 'browsing' so making it part of the web is extremely natural.
When you have a VR headset plugged to your computer, navigating to the urls with WebVR compatible code will add an extra button. Clicking on the button will display a scene inside your VR Headset. This scene can be interactive (using the remote control). It can be a full game, a video, anything...exactly like any experience you can download on Steam.
I think it simply means that the runtime and distribution platform are the typical browser technologies stack, namely JavaScript, HTTP, et al.
Here is a great list of examples: https://mozvr.com/#showcase
The future of the VR web: everyone who uses it gives patent indemnity across their whole portfolio to Facebook. Facebook only gives reciprocation across the narrow patents covered by React/ReactVR, not their full portfolio.
If you build a part of your business on this, they can pull the license if you sue them for infringement in some completely unrelated area and leave you screwed.
I really want WebVR to work but when I tested with a Chromium WebVR-capable build I ran into a bunch of aframe samples that claimed my browser was not VR capable, some that were really choppy in performance, and a handful thay worked correctly.
After that I started thinking I should just build in Unity because there was a much greater liklihood of people actually using it with a client they download that actually works rather than hoping they would have a working browser for WebVR.
I also would like to have browser windows available inside of VR for interfacing with remote desktops or any existing 2d interface. Which you can do that with Unity using a browser component from the Asset Store.
But I would prefer using JavaScript/A-Frame if it would actually work for most people.
It seems that Altspace maybe is some custom build of Chromium build because they support aframe.
WebVR and browsers and library versions are very much in flux. It is definitely early-adopter and experimental mode, although WebVR is on clear tracks to get to release versions of browsers: https://iswebvrready.org
Totally fine to not want to deal with all of that now. We're all eager for the day that WebVR is stable and in the hands of hundreds of millions.
Who wrote this release copy? Full of English errors...
ctrl-F: "vrml"
welp, now I feel old.
Don't feel too old; VRML is mentioned (usually in snark) just about every time a WebVR framework is discussed. Always found the comparisons weird though: one is a standardized file format, the others are JS frameworks.
So, where is all the real work being done?
Oh, that's right, by THREE.js inside the normal WebGL API.
This is just a fancy way to execute a banal-ly simple 3D scene that takes a single parameter - what text to show. It doesn't do much and I don't see any useful abstractions for the usual 3D primitives and doesn't meet the requirements of 3D programming in general.
Well you've obviously downloaded the code, fully immersed yourself in it's architecture and anticipated it's future limitations.
Or maybe you just skimmed the blog post in 30 seconds and decided to be negative for the sake of it?
From reading some of the other replies to you, there is an interesting point to be made about how state is managed in this and whether it has any of the same architectural underpinnings of react.js or react native. But you didn't bother to make that point and ended up just sounding grumpy and disinterested. I've read several people recently say they avoid reading HN because of this kind of snark and others say it's made them feel like they wasted their time building something.
Oh come on, read the rest of the blog post.
It's clearly doing more than you are implying it is.
From what I can see it looks like it's giving you a react-looking way of managing objects, views, and "stuff" for a VR application. It is working with a lot of other things to do some of the heavy lifting rendering wise, but that doesn't mean you can just shrug off the work that's going into this as not "real".
Besides, they are calling it "pre-alpha". Complaining that it's not doing much before it's much more than a name seems overly negative for no reason.
Yeah, I played with react-aframe and a couple other webvr experiments over the summer. A huge benefit of virtual dom in web dev is immutability and programming with immutable state. But all these experimental libraries are backed by THREE.js which means your state is done with traditional imperative math primitives. Just composing a scene in React is not very interesting because the real fun is in interacting with the state of all the objects, for example coding physics. So in the end it does not feel like React. Though Arcadia (experimental Unity engine adapter for Clojure, a functional programming language) is onto a way to bridge these imperative and functional worlds, the fundamental abstraction of Arcadia is to dehydrate a fat object instance into immutable data, then you can program with immutable data, and then hydrate the data back into the fat object instance (which is optimized for use with Unity and the underlying imperative hardware). E.g. https://github.com/arcadia-unity/Arcadia/blob/6105770a780194...
Here are some related notes i dumped on reddit in April 2016 maybe helpful, about doing VR from Clojure: https://www.reddit.com/r/Clojure/comments/4sgjhz/new_clojuri...
Why would you want immutable state for any kind of simulation? It seems like you'd just be adding a whole bunch of overhead for no real gain.
It uses the declarative syntax of React to compose views. The benefit is the common abstraction which will allow people familiar with React to quickly get something running.
Why the negativity?
But it has React word in it so it must be great.
How do I say that this is total bullshit without being spotted as redditor?
"VR is the next platform, it's just not ready yet."