React Renderer for Three.js

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • react-three-fiber

    🇨🇭 A React renderer for Three.js

    As I said, "schedule" just means "defer work to the next frame". That's a valid strategy if you have severe load, but it's not globally applicable: one might imagine that two components need to be updated together (e.g. updating the arms and body of a character should not be split up between two frames, or else the user will see split bodies for in-between frames). At the very best, this sort of scheduling should be informed by gameplay systems.

    It can "effortlessly outperform" only if we're talking about throughput, not latency here -- the scheduler ensures that less is done each frame, at the expense of having things done frames later than when they probably should have been.

    But the other thing wrong with this is the implication that 2,000 cubes should not have 700ms of load to begin with. The test you linked me to is not the same test. The test in the tweet is seen here [0], and has no artificial runtime delay as far as I can tell. For extra irony, note that they already have to bypass React (which is described as ItemSlow), in favor of the "Zustand approach", aka modifying things imperatively.

    I'm aware this is all a React feature. I disagree with the React team that concurrency is a superior solution to performance in all cases.

    [0] https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42...

  • beatmapper

    Discontinued A 3D editor for creating Beat Saber maps

    I've built "vanilla" Three.js projects, and worked with react-three-fiber. It is incredibly useful.

    Having a new set of "primitives" that map to three.js objects and being able to render them in a React application makes so many things easier. It's also just way less code to write compared to standard three.js.

    RE: animation performance, I haven't had any issues with it. I presume either they're doing a bunch of optimizations, or the concerns are greatly exaggerated. You can check out an app I built using it if you want some proof: https://beatmapper.app/

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • scheduler-test

    this is the test you are referring to: https://github.com/drcmda/scheduler-test it tested against severe stress. the cubes had artifical runtime delay, which would clog the main thread. the github repo now contains a vanilla test that you can run, it will block your cpu for 1-2 seconds. this is repeated every 2 seconds. a vanilla app trying to get through this will consequently go to its knees, but react can schedule it away.

    this btw, as absurd as it may seem to you, is a react feature. the upcoming react 18 release is pretty much based on it.

  • emscripten

    Emscripten: An LLVM-to-WebAssembly Compiler

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

  • x_ite

    X_ITE X3D Browser, view and manipulate X3D and VRML scenes in HTML.

    I mean, this looks like a nice, more modern approach - but vrml did allow full interaction? For something that works in current browsers, see eg:

    https://github.com/create3000/x_ite/wiki/Sensing-viewer-acti...

  • shipyard

    Entity Component System focused on usability and flexibility.

    It's not that it's incompatible, it's that when the ECS is the primary tool for organization, a DOM tree (or scenegraph) is merely one way of iterating over the entities - not the way.

    This provides tons of benefits, so for example you can also decide to iterate over the entites by shader program and gain significant speedups for graphics processing, or maintain components that roughly sort them by their position in world space for physics and culling or lighting, etc.

    To add to the sibling comment, there's another wonderful Rust ECS called shipyard[0] and I helped write a scenegraph for it (which I really need to update, one of these days)[1]

    [0] https://github.com/leudz/shipyard

  • shipyard-scenegraph

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • awsm-web

    I wrote an opinionated WebGL wrapper in Rust/WASM here: 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"

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts