6 ms·

For anyone wondering: 'Why JavaScript? Why React?', let me remind you, the goal of ReactVR is not to create the most performant game, but to allow the people th

For anyone wondering: 'Why JavaScript? Why React?', let me remind you, the goal of ReactVR is not to create the most performant game, but to allow the people that are creating websites right now, to create VR websites in future. Using the same technologies is natural.

javajosh 10y ago
I would add that there is absolutely no technical reason why an application expressed in one language need not be as fast as an application expressed in another. First, compilers improve static analysis, and second, JIT analysis will also improve. For this sort of thing, running on the GPU matters a lot more than source language, and WebGL has you covered there.
- meheleventyone 10y ago
  In the real world case though there are lots of extant technical reasons why this won't be as performant. As the parent says though it's okay for its usecase.
  - positivecomment 10y ago
    In the meanwhile many people like me who love TS/Flow wait for the days when their annotations could be used to optimize their apps. If types on JS doesn't come I'm sure someone will compile TS to WebAssembly or something. I'd be in even just for the possibility for reflection/dependency injection.
- Rusky 10y ago
  This is wrong. There absolutely are technical reasons why implementations of different languages perform differently- no amount of static or runtime analysis can entirely save you from performance-hostile semantics baked into the language spec. WebGL is a huge bonus, but WebAssembly will also be important for a lot of web-based VR.
  - avaer 10y ago
    > no amount of static or runtime analysis can entirely save you from performance-hostile semantics baked into the language spec You can in almost all cases check for these semantics statically, and if not found, run a super fast path. This is the whole premise behind asm.js. Heck, even C++ has plenty of features that have performance-hostile semantics. But the compiler checks for these and you don't pay the penalty if you don't use them. Wasm will help, but I disagree that anything in the JS spec makes the _language itself_ inherently slower than any other language, if we disregard textual compilation overhead.
    - vvanders 10y ago
      I'll give you one: value types. Until you can specify memory layout you'll never come near a proper gamedev engine, regardless of GC issues(which are also a problem). (source: I used to work on professional game engines)
      - Klathmon 10y ago
        Luckily most JS engines "unbox" simple values to "value types" if it can be determined that they will stay that way. so aside from startup speed you get the same perf
        vvanders 10y ago
        > simple values So does every other language, where it matters is with objects. Until I can mark a whole object as a value type and fix it in memory relative to other objects then you'll pay a 10-50x slowdown for cache misses and the like.
        Klathmon 10y ago
        Sorry, that should have said "simple objects". But you don't even need to rely on that. JS has TypedArrays[0] which are basically just a chunk of memory you can read and write to. Aside from some bounds checking, it's about as "low level" as you can get. Sounds like exactly what you are looking for. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
- ethbro 10y ago
  > I would add that there is absolutely no technical reason why an application expressed in one language need not be as fast as an application expressed in another. There absolutely is. If I write a program in a language that's fuzzy enough that a machine (which follows the specifications of the language) cannot definitely tell what I was asking it to do at compile time, there are compiled optimizations it can never rely on. You make a good chunk of that back with JIT / predictive runtime compiling, but it's never going to be the same. At minimum, you're burning CPU and cache on your miss rate. To say nothing of the additional overhead of running JIT while executing in the first place. As I understand it, this is the entire purpose of things like Vulkan / Webasm. (I realize they're primitive targets vs high level language, but same principle applies at any level of the stack) Happy to have someone tell me I'm wrong, but the original quote flies in the face of everything I learned in language / compiler design.
  - javajosh 10y ago
    This is a good comment. Ideally, JIT would reach some asymptotic improvement and then stop running. It would only need to start running again if the code changes. I think however there is some fundamental communication issues talking about "compilers vs language". Optimizing compilers, by definition, rewrite your code into a "better" form. Even if you are writing C/C++ you probably don't really know what's happening at the register level. Heck, with todays CPUs I wonder if even assembly people know what's actually happening in the registers!
    - ethbro 10y ago
      And in x86 at least, even the assembly gets sliced and diced behind the scenes. There have been comments to the same effect on HN before, but I look at language design as an API between humans and computers. Computers need as strict rules on how to execute a thing as possible: humans need something comprehensible. The ideal language finds ways you can increase the former without decreasing the latter (in ways they notice).
- flohofwoe 10y ago
  Theoretically that may be true, but in reality there are a lot of little detail problems which cannot simply be hand-waved away. For instance, WebGL behaves very differently compared to a native 3D API, mainly because there's a much longer pipeline for each call from JS to the driver. Manually written JS has garbage collection spikes, input and audio have much higher latency. I think WebVR provides shortcuts for some of those problems, and mobile/web VR content needs to be designed with those limitations in mind, I just want to point out that the browser platform is full of technical limitations and compromises compared to 'bare metal' platforms which at most can be softened a bit, but will never completely disappear, no matter how much code is thrown at the problems.
leggomylibro 10y ago
Javascript I get, but React? Why use a flavor-du-jour library for something like this?
- nbardy 10y ago
  It's about having a declarative UI library. React is just the syntax Facebook prefers.
- mikewhy 10y ago
  People have been using React since 2014. Is 3 years really still "du jour"?
  - user15672 10y ago
    Yes, yes it is
  - leggomylibro 10y ago
    Certainly, compared to something solid and well-understood like Javascript which has been around since 1997. I'd complain the same way if it were a C++ project requiring Boost or something.
    - Sacho 10y ago
      Boost has existed since 1999-2000, which aligns with ES3. As for solid and well-understood... Douglas Crockford wrote a book on how "solid" Javascript is, called "Javascript: The Good Parts". One of his most common refrains about JS was "Javascript is The World's Most Misunderstood Programming Language". [0][1] ES5 came out in 2009. ES6 was standardized after React came out. [0] - http://javascript.crockford.com/javascript.html http://javascript.crockford.com/javascript.html [1] - http://javascript.crockford.com/popular.html http://javascript.crockford.com/popular.html
  - flukus 10y ago
    Yes absolutely. Unfortunately in the javascript world it probably means that it's legacy by now.

javajosh 10y ago

I would add that there is absolutely no technical reason why an application expressed in one language need not be as fast as an application expressed in another. First, compilers improve static analysis, and second, JIT analysis will also improve. For this sort of thing, running on the GPU matters a lot more than source language, and WebGL has you covered there.

meheleventyone 10y ago
In the real world case though there are lots of extant technical reasons why this won't be as performant. As the parent says though it's okay for its usecase.
- positivecomment 10y ago
  In the meanwhile many people like me who love TS/Flow wait for the days when their annotations could be used to optimize their apps. If types on JS doesn't come I'm sure someone will compile TS to WebAssembly or something. I'd be in even just for the possibility for reflection/dependency injection.
Rusky 10y ago
This is wrong. There absolutely are technical reasons why implementations of different languages perform differently- no amount of static or runtime analysis can entirely save you from performance-hostile semantics baked into the language spec. WebGL is a huge bonus, but WebAssembly will also be important for a lot of web-based VR.
- avaer 10y ago
  > no amount of static or runtime analysis can entirely save you from performance-hostile semantics baked into the language spec You can in almost all cases check for these semantics statically, and if not found, run a super fast path. This is the whole premise behind asm.js. Heck, even C++ has plenty of features that have performance-hostile semantics. But the compiler checks for these and you don't pay the penalty if you don't use them. Wasm will help, but I disagree that anything in the JS spec makes the _language itself_ inherently slower than any other language, if we disregard textual compilation overhead.
  - vvanders 10y ago
    I'll give you one: value types. Until you can specify memory layout you'll never come near a proper gamedev engine, regardless of GC issues(which are also a problem). (source: I used to work on professional game engines)
    - Klathmon 10y ago
      Luckily most JS engines "unbox" simple values to "value types" if it can be determined that they will stay that way. so aside from startup speed you get the same perf
      - vvanders 10y ago
        > simple values So does every other language, where it matters is with objects. Until I can mark a whole object as a value type and fix it in memory relative to other objects then you'll pay a 10-50x slowdown for cache misses and the like.
        Klathmon 10y ago
        Sorry, that should have said "simple objects". But you don't even need to rely on that. JS has TypedArrays[0] which are basically just a chunk of memory you can read and write to. Aside from some bounds checking, it's about as "low level" as you can get. Sounds like exactly what you are looking for. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays https://developer.mozilla.org/en-US/docs/Web/JavaScript/Type...
ethbro 10y ago
> I would add that there is absolutely no technical reason why an application expressed in one language need not be as fast as an application expressed in another. There absolutely is. If I write a program in a language that's fuzzy enough that a machine (which follows the specifications of the language) cannot definitely tell what I was asking it to do at compile time, there are compiled optimizations it can never rely on. You make a good chunk of that back with JIT / predictive runtime compiling, but it's never going to be the same. At minimum, you're burning CPU and cache on your miss rate. To say nothing of the additional overhead of running JIT while executing in the first place. As I understand it, this is the entire purpose of things like Vulkan / Webasm. (I realize they're primitive targets vs high level language, but same principle applies at any level of the stack) Happy to have someone tell me I'm wrong, but the original quote flies in the face of everything I learned in language / compiler design.
- javajosh 10y ago
  This is a good comment. Ideally, JIT would reach some asymptotic improvement and then stop running. It would only need to start running again if the code changes. I think however there is some fundamental communication issues talking about "compilers vs language". Optimizing compilers, by definition, rewrite your code into a "better" form. Even if you are writing C/C++ you probably don't really know what's happening at the register level. Heck, with todays CPUs I wonder if even assembly people know what's actually happening in the registers!
  - ethbro 10y ago
    And in x86 at least, even the assembly gets sliced and diced behind the scenes. There have been comments to the same effect on HN before, but I look at language design as an API between humans and computers. Computers need as strict rules on how to execute a thing as possible: humans need something comprehensible. The ideal language finds ways you can increase the former without decreasing the latter (in ways they notice).
flohofwoe 10y ago
Theoretically that may be true, but in reality there are a lot of little detail problems which cannot simply be hand-waved away. For instance, WebGL behaves very differently compared to a native 3D API, mainly because there's a much longer pipeline for each call from JS to the driver. Manually written JS has garbage collection spikes, input and audio have much higher latency. I think WebVR provides shortcuts for some of those problems, and mobile/web VR content needs to be designed with those limitations in mind, I just want to point out that the browser platform is full of technical limitations and compromises compared to 'bare metal' platforms which at most can be softened a bit, but will never completely disappear, no matter how much code is thrown at the problems.

leggomylibro 10y ago

Javascript I get, but React? Why use a flavor-du-jour library for something like this?

nbardy 10y ago
It's about having a declarative UI library. React is just the syntax Facebook prefers.
mikewhy 10y ago
People have been using React since 2014. Is 3 years really still "du jour"?
- user15672 10y ago
  Yes, yes it is
- leggomylibro 10y ago
  Certainly, compared to something solid and well-understood like Javascript which has been around since 1997. I'd complain the same way if it were a C++ project requiring Boost or something.
  - Sacho 10y ago
    Boost has existed since 1999-2000, which aligns with ES3. As for solid and well-understood... Douglas Crockford wrote a book on how "solid" Javascript is, called "Javascript: The Good Parts". One of his most common refrains about JS was "Javascript is The World's Most Misunderstood Programming Language". [0][1] ES5 came out in 2009. ES6 was standardized after React came out. [0] - http://javascript.crockford.com/javascript.html http://javascript.crockford.com/javascript.html [1] - http://javascript.crockford.com/popular.html http://javascript.crockford.com/popular.html
- flukus 10y ago
  Yes absolutely. Unfortunately in the javascript world it probably means that it's legacy by now.