I only vaguely understand this wizardry, but it sounds cool. The Use.GPU framework is in alpha and requires WebGPU which isn't yet available in any production browser. Apparently it's possible to...
I only vaguely understand this wizardry, but it sounds cool.
The Use.GPU framework is in alpha and requires WebGPU which isn't yet available in any production browser. Apparently it's possible to download a development version of a browser to run it, but I just looked at the videos.
I was thinking exactly that! The closest I’ve come to anything like this is a bit of 2D WebGL work using very high level libraries, and all that’s really done here is underline how much there is I...
I only vaguely understand this wizardry, but it sounds cool.
I was thinking exactly that! The closest I’ve come to anything like this is a bit of 2D WebGL work using very high level libraries, and all that’s really done here is underline how much there is I don’t know about graphics and rendering, but the concept of a unidirectional mapping from data to static 3D objects that also diffs fast enough to animate without breaking those assumptions seems extremely useful for things like AR/VR UI. “It has all the benefits of immediate-mode UI, with none of the downsides, and tons of extensibility” is a great sales pitch, and (unsurprisingly) quite similar to the one I was hearing for React itself, years ago now.
I ended up reading his previous post as well, which is much more focused on architectural decisions I do understand, and I think he’s got some very good points - although it’s a pretty long ramble and it does veer more than I’d like into “kids today” grumbling a few times.
I’ve finally had a chance to sit down and really read that, and it was fascinating. It was pitched pretty much perfectly to bridge from what I knew already to what I didn’t follow in the most...
I’ve finally had a chance to sit down and really read that, and it was fascinating. It was pitched pretty much perfectly to bridge from what I knew already to what I didn’t follow in the most recent post, and I genuinely feel like I’ve learned some quite fundamental things here, which is alway exciting - thanks for suggesting it!
It’s interesting that the data flow decisions aren’t just for developer friendliness: they’re also necessarily strict to maintain the cache functionality. In the spirit of “everything reverts to lisp in the end”, I’m seeing some noticeable echoes of Clojure here; the cache and dependency tracking hooks come for free with atoms and cursors, and the underlying reasons for using them brings the branching immutable memory model to mind. His gather “repeatable promises” look like a conceptual match to the core.async state machine. And the fact it all depends on closures to maintain full stack frames is right there in the language name! Anything that pulls mainstream web development more in that direction is more than fine with me.
I only vaguely understand this wizardry, but it sounds cool.
The Use.GPU framework is in alpha and requires WebGPU which isn't yet available in any production browser. Apparently it's possible to download a development version of a browser to run it, but I just looked at the videos.
I was thinking exactly that! The closest I’ve come to anything like this is a bit of 2D WebGL work using very high level libraries, and all that’s really done here is underline how much there is I don’t know about graphics and rendering, but the concept of a unidirectional mapping from data to static 3D objects that also diffs fast enough to animate without breaking those assumptions seems extremely useful for things like AR/VR UI. “It has all the benefits of immediate-mode UI, with none of the downsides, and tons of extensibility” is a great sales pitch, and (unsurprisingly) quite similar to the one I was hearing for React itself, years ago now.
I ended up reading his previous post as well, which is much more focused on architectural decisions I do understand, and I think he’s got some very good points - although it’s a pretty long ramble and it does veer more than I’d like into “kids today” grumbling a few times.
I went back to this earlier post which explains more of the high-level architecture in a way I'm familiar with.
I’ve finally had a chance to sit down and really read that, and it was fascinating. It was pitched pretty much perfectly to bridge from what I knew already to what I didn’t follow in the most recent post, and I genuinely feel like I’ve learned some quite fundamental things here, which is alway exciting - thanks for suggesting it!
It’s interesting that the data flow decisions aren’t just for developer friendliness: they’re also necessarily strict to maintain the cache functionality. In the spirit of “everything reverts to lisp in the end”, I’m seeing some noticeable echoes of Clojure here; the cache and dependency tracking hooks come for free with atoms and cursors, and the underlying reasons for using them brings the branching immutable memory model to mind. His
gather“repeatable promises” look like a conceptual match to thecore.asyncstate machine. And the fact it all depends on closures to maintain full stack frames is right there in the language name! Anything that pulls mainstream web development more in that direction is more than fine with me.