Ok, you were used to say that Hyperfiddle would be impossible to implement without an immutable DB like Datomic, and if I understand you well, this requirement got dropped. 🙂

1h23 minutes of interesting stuff!? Are they sufficiently knowledgeable to be that interesting that long!? 🙂

If we've been following hyperfiddle for the past years do you think we'll learn something, does it connect well with all sorts of external concerns, or is it much more about beginning to understand hyperfiddle? Always a lot of resistance before starting to invest time in youtube videos.

I've listened to the first 15 minutes now and they are indeed knowledgeable.

I've listened to the whole discussion while multi-tasking (I'm a bad multi-tasker). They brought a lot of interesting concepts to the table. Their strength seems to be about relating general concepts. They didn't explain in details how Photon and Missionary are implemented.

Yeah not worth, its just hype

Hyperfiddle's staging area takes advantage of database-as-a-value, but the staging area is not mandatory. Also we can probably just add LOC to deal with it. We have LOC budget to spare 🙂

Your last sentences are what finally made it click for me about why you used to say that Datomic's immutability is key to Hyperfiddle. ...for its staging area feature. Thanks!

thank you for asking this; short answer is either use a streaming database (most modern cloud data layers provide reactive subscriptions) or localize the updates (reactive update interval aka sampling frequency can be manipulated locally with standard missionary frp primitives). we will provide solutions when we reach the scale that is worth investigating this

there are several promising infra startups that abstract over query diffing and generalized incremental maintenance on top of arbitrary data sources

https://readyset.io is one; hasura also solves this in a great way

you can always degrade to whatever todays CRUD apps are doing, this is a problem with relational databases not Photon so the problem is not unique to us. for example you can also just pin time as if it was a server rendered page and refresh at key interactions like clicking a link or submitting a form; i believe this is Phoenix LiveView model

your backend can also do intelligent things in the query layer, your queries are written in clojure/java/js not photon and it's BYO database so this is in your control to deal with

https://www.apollographql.com/docs/react/data/subscriptions/

https://abulasar.com/building-realtime-liveview-app-using-phoenix-pubsub - LiveView makes you write out the pubsub to implement the server push as a special case

I see your point about this not being Photon's problem. However, in the traditional SPA architecture there would be a UI cache layer between the DOM and the db, and this layer can more easily do 'granular reactivity' (and optimistic updates). (So similar in spirit to the abstraction your brought up.) Most of the time one doesn't really need to run full-scale db queries to update the UI. Of course, this layer increases complexity. Anyway, thanks for the detailed response! I'm looking forward to seeing solutions for those of us 'stuck' with clj datalog dbs.

are you talking about client side database/orm architectures? that can be built in userland in photon. even more interesting than that - datascript/datomic can be rebuilt in Photon and now the “DAG slice” can cut right through the query engine and it's internal data structures, such that indexes are partially on the client and the final stages of query filtering are on the client- a distributed database with managed network

that's like 3 man months for someone like Tonsiy to reimplement datascript in photon if he types fast as the clojure reference implementation is mostly reusable

> a distributed database with managed network That would be a https://www.youtube.com/watch?v=ewoFTfAQnUI 🙂