5 ms·

When AR/VR finally happens, UI developers will have to deal with complexity from a completely different paradigm. For me, React's biggest strength has always be

• deleted 5y ago
  [deleted]
• nobbis 5y ago
  As a counterpoint, I've enjoyed building VR on the web using C++ (with WebAssembly/WebGL/WebXR) and not having to touch the DOM or JS, see: https://twitter.com/nobbis/status/1425266634982248451 https://twitter.com/nobbis/status/1425266634982248451 Benefits include complete control at frame and pixel level, being cross-platform (same code runs on web, iOS, macOS, Linux), and having access to third-party C/C++ libraries for 3D graphics.
  • brailsafe 5y ago
    This looks really neat
  • nightski 5y ago
    I have not put a lot of time into learning WebAssembly. But isn't WebGL a JavaScript API? Meaning wouldn't you be going from WebAssembly -> JavaScript engine -> WebGL? I was under the impression WebAssembly had no access to the outside world and could only access the relevant JavaScript APIs. But if it is true you can basically do WebAssembly -> native GL then that would be amazing.
    • nobbis 5y ago
      You're correct. WebGL does require extra validation compared to native GL, but it's effectively the same API as OpenGL ES 2.0/3.0 and Emscripten handles the translation from C/C++ for you. There's some overhead but it's negligible (assuming you're not making overly redundant API calls.)
      • rock_hard 5y ago
        This is how Figma does it
      • shadowgovt 5y ago
        And that last part is key: for modern high-performance graphics acceleration, the name of the game is "maximum throughput with minimum API interactions." If your data isn't structured for fast rendering, it doesn't matter much what language you're using; they'll all be too slow.
    • Jasper_ 5y ago
      emscripten ships a "desktop GL" emulation library [0], which can have quite a bit of overhead. If you want something faster, you can use the native WebGL bindings [1] [0] https://github.com/emscripten-core/emscripten/blob/main/src/library_glemu.js https://github.com/emscripten-core/emscripten/blob/main/src/... [1] https://github.com/emscripten-core/emscripten/blob/main/tests/webgl2.cpp https://github.com/emscripten-core/emscripten/blob/main/test...
      • nobbis 5y ago
        The "native WebGL bindings" still call into JS. Desktop GL emulation is just a layer on top OpenGL ES if, for example, you're still using OpenGL's fixed function pipeline (deprecated 13 years ago.)
    • Unit520 5y ago
      WebAssembly has no access to the outside world at the moment, that is correct. It is only able to call (and be called by) JS. A C++ application compiled via Emscripten ships (a fairly large amount) of JS glue code that exposes all relevant Browser APIs like WebGL, Fetch or other HTML5 stuff to the actual WASM program. As others commented, for WebGL an additional API translation is applied. If the source targets OpenGL ES 2 (or 3 for WebGL 2), this step has almost no overhead however.
      • nobbis 5y ago
        Not that large. The JS glue code for the VR web page referenced above is 48 KB, including WebGL, WebXR, Fetch, etc.
    • dakom 5y ago
      I wrote an opinionated WebGL wrapper in Rust/WASM here: https://github.com/dakom/awsm-web https://github.com/dakom/awsm-web The idea is that it does more cacheing of things like uniform locations and such so you do very fast in-memory lookups in WASM without hitting the JS Api as much. In the future this will be obsolete since WebGPU has a more optimal API to begin with, and Rust/WASM won't need to go through the JS layer due to "interface types"
• short_sells_poo 5y ago
  I think they need to take a very serious and hard look at performance before it can go anywhere near VR (where rendering speed and stability are paramount). I'm sure it works for simple things and can handle GUIs fine, but the overhead seems huge currently.
  • mlsarecmg 5y ago
    there are many large scale apps built with it these days. it was initially made for complex use cases, to bring order into the scene graph, and of course to optimize raw rendering performance: https://docs.pmnd.rs/react-three-fiber/advanced/scaling-performance https://docs.pmnd.rs/react-three-fiber/advanced/scaling-perf...
• rock_hard 5y ago
  Totally agree! We switched https://flux.ai https://flux.ai from vanilla ThreeJS to R3F and it’s been a huge productivity gain for the whole team! Less code, that is more capable and more reusable! In case anyone is interested, we are hiring: https://coda.io/@flux-ai/flux-jobs https://coda.io/@flux-ai/flux-jobs
  • nobbis 5y ago
    Is this AR/VR? It looks like 2D circuit schematics.
    • rock_hard 5y ago
      It’s 2D schematics and 2D/3D PCB layout. All powered by r3f though PCB layouting hasn’t publicly shipped yet though
• hirako2000 5y ago
  Except that for three.js, it's react introducing complexity rather than improving the organisation of the code. A simple component with defaults look neat, but start building a complex scene and jsx gets in the way. three.js isn't dom elements updated in js. The state of each object is updated in the scene depending on more than whether they changed. Where three.js lacks abstraction is a component system, in plain js, to organise application with decent patterns. Most three apps are a big blob or code.
  • runawaybottle 5y ago
    Okay yes, thank you from saving me from my drivel. Why would three.js care about representing a document model, bubbling up events, and so on. If we do this, we do it fresh.
• pjmlp 5y ago
  BabylonJS and PlayCanvas do it just right without jumping into React fashion.
• deleted 5y ago
  [deleted]
• webgfxdev 5y ago
  React is one of the worst choices of doing something like that. The underlying abstraction model of having a tree of components and re-rendering only the parts that have changed between renders doesn’t map to the hardware at all, meaning you’ll waste most of the HW performance just on maintaining the abstraction. You’ll also get zero benefits from the third-party libraries - there’s nothing in them that can help you with stuff that matters, like minimizing amount of the GPU state transitions for example or minimizing amount of GPU/CPU syncs. It will be scenegraphs all over again, and the graphics industry has ditched these long ago in favor of simpler models, for good reasons. Long story short, the happy path in graphics programming is very narrow and fragile, and you typically want to structure your abstraction around it.
  • mlsarecmg 5y ago
    You are arguing against threejs not react. R3f reconciles threejs in the exact way it's getting used, a graph. This ofc is also how blender gltf et al work. If you make a webgl app on the web you most likely use three and all react does is make that a little ordered with some additional benefits when it comes to performance, memory and interop.
  • xrobledo84 5y ago
    What is wrong with scenegraphs? And what is the graphics programming using instead?
• tuckerconnelly 5y ago
  I really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee in the cup? Is that a child of the cup? How do you change properties of the coffee without necessarily accessing the table and the cup? Developers working on 3D systems have developed much better paradigms than the DOM for dealing with this problem. An Entity-Component-System architecture with "constraints" is the current best solution. In that architecture, you would create a coffee cup "entity" with a mesh "component" with another "constraint" component, constraining that coffee cup to the table (or better yet, mass component acted on by a physics system). Then you can simply remove the constraint component when removing the cup from one table, and re-add the constraint component when adding it to the other table. Overall, I think web developers are in for some intense learning and paradigm shifts if 3D becomes the norm.
  • SirHound 5y ago
    Aren’t nested coordinate systems a quite natural match for a DOM-like tree structure?
  • rock_hard 5y ago
    Nothing in R3F prevents you from organizing your scene like that
  • strbean 5y ago
    I don't see why an ECS would be incompatible with a DOM tree. As for the gorilla-banana problem, I would think all objects in a scene would be under the root, with the exception of pieces that make up a thing and rarely separate (wheels on a car, for example).
    • tuckerconnelly 5y ago
      While not incompatible with ECS, the DOM and this renderer go all-in on the javascript event-loop. You would have to write your own run loop, which executes the systems on every frame (ideally creating a DAG and executing in parallel while possible), and leave the event loop behind, with all the niceties like `onClick`, to go full ECS. Otherwise you'll create some Frankenstein monster of part ECS, part event-loop, part declarative React. Additionally, you can throw OOP in that mix as well, because Three.js has it's own whole OOP-style framework, that you're strapping declarative React on top of with this renderer. Reminds me of Jonathan Blow's talk on the end of civilization via endless layers of abstraction[1]. I really think, when it's ready, a Bevy[2]-style system either native or compiled to WASM with WebGPU will be ideal. And while I'm airing opinions (forgive me), I think writing shaders now is like SQL 30 years ago. Developers left optimizing difficult--according to them--SQL to database administrators by abstracting it away into ORMs. If history is any indicator, I think we'll be having the same arguments on Hacker News 30 years from now about 3D frameworks vs writing shaders directly as we're having now about ORMs vs writing SQL directly. [1] https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk [2] https://bevyengine.org/ https://bevyengine.org/