Hacker News Reader

Comment by brundolf | Hacker News Reader

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

View on HN

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.

It makes well enough sense. I was mainly surprised specifically because this is a game, not a DOM-based web app

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

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

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/

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.

Hmm ah okay I meant the write-off omnext, my bad, didn't realize there was previous history, I stand corrected

Fulcro is the successor of OM, a full-stack framework, with some very interesting characteristics and features.

You are right. Equality checks for any complex data-structure in JS (and TypeScript) are cumbersome as hell, yet for a React architecture they are crucial for performance.

This is how remember things historically.

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

This exists in JS/TS too. Check out SolidJS (and most relevant its underlying dom-expressions Babel transform).

I don't think they're actually doing any compiling in this demo though, but maybe I'm mistaken?

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

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.

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 or scale quality: https://twitter.com/0xca0a/status/1407371461447368705 These things would require a framework around Threejs.

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.

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.

It is a using custom renderer indeed: 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.

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.

Reply on news.ycombinator.com