5 ms·

The more surprising/interesting thing to me is that it uses React. I'd be curious to see a performance breakdown (how much headroom is left for a more complex g

The more surprising/interesting thing to me is that it uses React. I'd be curious to see a performance breakdown (how much headroom is left for a more complex game?) I am also curious how Clojure(Script)'s persistent data structures work out for data structures that update 30 or 60 times per second. That's a lot of allocation and deallocation

bobopa 5y ago
This example has less than 20 components in total and the max depth is 3. (The whole arena is a single object). And it's still using 10% of cpu. Production games have a lot more components in comparison: https://www.youtube.com/watch?v=GuzRQ1IJkaI https://www.youtube.com/watch?v=GuzRQ1IJkaI
- nimih 5y ago
  The baseline performance for any sort of react-based web app is going to be pretty bad if you're comparing it to a state-of-the-art game engine. The build status page for the CI/CD pipeline we use at my work has around 2x the CPU usage as this demo, for instance. It would be surprising if cljs's persistent data structures are incurring any real user-perceivable cost over JS arrays and maps, given how small this project is. That being said, it would be interesting to know how much of a penalty you pay as N gets big using a deeply nested persistent record vs a flatter component system with immutable persistent structures vs a pile of mutable structures.
lrenn 5y ago
You could argue that Clojurescript early adoption of React was one of the reasons for it's rise. The early work of David Nolan (Om) and Dan Holmsand (Cloact->Reagent) were, at least in my opinion, pretty influential. Clojure's immutable data structures were (are) a perfect fit. iirc, the fact that "shouldComponentUpdate" could be performant with equality was a huge, easy performance/simplicity win. I may be way off about that, if so, I apologize.
- brundolf 5y ago
  It makes well enough sense. I was mainly surprised specifically because this is a game, not a DOM-based web app
- endergen 5y ago
  This is how remember things historically.
- erromno 5y ago
  Om was late, not early, around mid 2015, turned out to be experiment and eventual abandonware. There were much earlier react wrappers, and frameworks like reagent that remain popular today. Dave was influencial in cljs but don't think he ever got a full spa framework off the ground, unless it happened in last few years
  - lrenn 5y ago
    Om came first, Cloact (eventually renamed Reagent due to an unfortunate similarity with a certain body part of a snake) came after it. Here is the original HN post about Cloact: https://news.ycombinator.com/item?id=7037038 https://news.ycombinator.com/item?id=7037038 You can see people comparing it to Om. Here is a blog post of his from 2013 that mentions Om: https://swannodette.github.io/2013/12/31/time-travel/ https://swannodette.github.io/2013/12/31/time-travel/ And yeah, Reagent "won" because it was way simpler but I'd find it hard to believe that it wasn't influence or inspired by Om.
    - deleted 5y ago
      [deleted]
    - erromno 5y ago
      Hmm ah okay I meant the write-off omnext, my bad, didn't realize there was previous history, I stand corrected
  - dgb23 5y ago
    Fulcro is the successor of OM, a full-stack framework, with some very interesting characteristics and features.
snicker7 5y ago
Like Svelte, Clojurescript can "compile" to reactive code (one advantage of being lispy) via Mr. Clean [1]. No VDOM, no library overhead. [1] https://bitbucket.org/sonwh98/mr-clean https://bitbucket.org/sonwh98/mr-clean
- westoncb 5y ago
  I don't think they're actually doing any compiling in this demo though, but maybe I'm mistaken?
- eyelidlessness 5y ago
  This exists in JS/TS too. Check out SolidJS (and most relevant its underlying dom-expressions Babel transform).
eyelidlessness 5y ago
There's a lot you can do with a custom reconciler. I didn't look to see if that's what's going on, but it's the foundation for many React adaptations to unlikely interfaces, such as Ink and some of Netflix's smart tv UIs.
- mlsarecmg 5y ago
  It is a using custom renderer indeed: https://github.com/pmndrs/react-three-fiber https://github.com/pmndrs/react-three-fiber it doesn't wrap Threejs, just expresses it via JSX similar to how react-dom expresses the dom.
fulafel 5y ago
Is this doing any dom stuff in gameplay after React optimizes away unchanged elements? Looks like just a WebGL canvas. I'd guess the React/dom time ends up near invisible in a profile.
RobertKerans 5y ago
Re React, it just uses the same interface: in this case performance is basically just what threejs' performance is (there's naturally a very slight overhead, but what you're looking at is a very thin wrapper over three) Edit: a sibling mentioned the React ART library and Ink, which are other good examples of the same thing. You can also see same principle used for many of the React animation libraries -- they use the same semantics, so they interop with "normal" React code just fine, but in actuality they're using the underlying animation APIs directly, bypassing the repatively expensive reconciliation process.
mlsarecmg 5y ago
React-three-fiber is a renderer for Threejs but does not introduce overhead. Games and webgl is loop driven, so React solves that with a hook, useFrame, which binds components to the render-loop in a managed way. It could in theory outperform Threejs because it can schedule: https://twitter.com/0xca0a/status/1383165072554532865 https://twitter.com/0xca0a/status/1383165072554532865 or scale quality: https://twitter.com/0xca0a/status/1407371461447368705 https://twitter.com/0xca0a/status/1407371461447368705 These things would require a framework around Threejs.

bobopa 5y ago

This example has less than 20 components in total and the max depth is 3. (The whole arena is a single object). And it's still using 10% of cpu. Production games have a lot more components in comparison: https://www.youtube.com/watch?v=GuzRQ1IJkaI https://www.youtube.com/watch?v=GuzRQ1IJkaI

nimih 5y ago
The baseline performance for any sort of react-based web app is going to be pretty bad if you're comparing it to a state-of-the-art game engine. The build status page for the CI/CD pipeline we use at my work has around 2x the CPU usage as this demo, for instance. It would be surprising if cljs's persistent data structures are incurring any real user-perceivable cost over JS arrays and maps, given how small this project is. That being said, it would be interesting to know how much of a penalty you pay as N gets big using a deeply nested persistent record vs a flatter component system with immutable persistent structures vs a pile of mutable structures.

lrenn 5y ago

You could argue that Clojurescript early adoption of React was one of the reasons for it's rise. The early work of David Nolan (Om) and Dan Holmsand (Cloact->Reagent) were, at least in my opinion, pretty influential. Clojure's immutable data structures were (are) a perfect fit. iirc, the fact that "shouldComponentUpdate" could be performant with equality was a huge, easy performance/simplicity win. I may be way off about that, if so, I apologize.

brundolf 5y ago
It makes well enough sense. I was mainly surprised specifically because this is a game, not a DOM-based web app
endergen 5y ago
This is how remember things historically.
erromno 5y ago
Om was late, not early, around mid 2015, turned out to be experiment and eventual abandonware. There were much earlier react wrappers, and frameworks like reagent that remain popular today. Dave was influencial in cljs but don't think he ever got a full spa framework off the ground, unless it happened in last few years
- lrenn 5y ago
  Om came first, Cloact (eventually renamed Reagent due to an unfortunate similarity with a certain body part of a snake) came after it. Here is the original HN post about Cloact: https://news.ycombinator.com/item?id=7037038 https://news.ycombinator.com/item?id=7037038 You can see people comparing it to Om. Here is a blog post of his from 2013 that mentions Om: https://swannodette.github.io/2013/12/31/time-travel/ https://swannodette.github.io/2013/12/31/time-travel/ And yeah, Reagent "won" because it was way simpler but I'd find it hard to believe that it wasn't influence or inspired by Om.
  - deleted 5y ago
    [deleted]
  - erromno 5y ago
    Hmm ah okay I meant the write-off omnext, my bad, didn't realize there was previous history, I stand corrected
- dgb23 5y ago
  Fulcro is the successor of OM, a full-stack framework, with some very interesting characteristics and features.

snicker7 5y ago

Like Svelte, Clojurescript can "compile" to reactive code (one advantage of being lispy) via Mr. Clean [1]. No VDOM, no library overhead. [1] https://bitbucket.org/sonwh98/mr-clean https://bitbucket.org/sonwh98/mr-clean

westoncb 5y ago
I don't think they're actually doing any compiling in this demo though, but maybe I'm mistaken?
eyelidlessness 5y ago
This exists in JS/TS too. Check out SolidJS (and most relevant its underlying dom-expressions Babel transform).

eyelidlessness 5y ago

There's a lot you can do with a custom reconciler. I didn't look to see if that's what's going on, but it's the foundation for many React adaptations to unlikely interfaces, such as Ink and some of Netflix's smart tv UIs.

mlsarecmg 5y ago
It is a using custom renderer indeed: https://github.com/pmndrs/react-three-fiber https://github.com/pmndrs/react-three-fiber it doesn't wrap Threejs, just expresses it via JSX similar to how react-dom expresses the dom.

fulafel 5y ago

Is this doing any dom stuff in gameplay after React optimizes away unchanged elements? Looks like just a WebGL canvas. I'd guess the React/dom time ends up near invisible in a profile.

RobertKerans 5y ago

Re React, it just uses the same interface: in this case performance is basically just what threejs' performance is (there's naturally a very slight overhead, but what you're looking at is a very thin wrapper over three) Edit: a sibling mentioned the React ART library and Ink, which are other good examples of the same thing. You can also see same principle used for many of the React animation libraries -- they use the same semantics, so they interop with "normal" React code just fine, but in actuality they're using the underlying animation APIs directly, bypassing the repatively expensive reconciliation process.

mlsarecmg 5y ago

React-three-fiber is a renderer for Threejs but does not introduce overhead. Games and webgl is loop driven, so React solves that with a hook, useFrame, which binds components to the render-loop in a managed way. It could in theory outperform Threejs because it can schedule: https://twitter.com/0xca0a/status/1383165072554532865 https://twitter.com/0xca0a/status/1383165072554532865 or scale quality: https://twitter.com/0xca0a/status/1407371461447368705 https://twitter.com/0xca0a/status/1407371461447368705 These things would require a framework around Threejs.