update my browser DB virtualaizer pursuit,
IDB is fast and OPFS is SUPER FAST
but still the biggest challenges of real time DB reads is the read request itself,
then once you are in DB you are good to go
so the constraints still are:
-single request on render === the delay of the request it self
-too many requests === slower
so the new idea is to eagerly fire the first read request
and prepare to hijack it
such hijack operation requires working on JS ticks, treating each tick as progression in time
so lets have an IDB example:
lets say the user is scrolling fast downward
tick one: indexes [1, 2, 3] are requested
tick two: [2, 3, 4]
tick three: [3, 4, 5]
third four: [4, 5, 6]
firing a request for each tick would result in 4 parallel read-requests aka "SLOW".
soo, we can compare tick 2 with tick 1 to derive the direction (assume defaults for tick 1) and open a read-request in that direction then let any future ticks in the same direction just hijack that same read-request rather than firing a new one
so in our example the read-request is fired against tick 1 but it might actually be used to retrieve tick 4
also in case our read-request got fulfilled on tick 3 but its still on-going then tick 4 can still hijack it and extend it instead of firing a new one
always prioritizing what is actually on the screen by the time a read-request is fulfilled.


Let's talk data persistence in js apps
Aka "js Client-only development"
After good dive into Indexedb and OPFS api's
I'm still developing my tool own and it's far from a finished product
Along the way I found this tool called DPP (Deep Persistent Proxy JS Objects)
https://github.com/robtweed/DPP
And I found it helpful to share it with more nostr goys
It runs on Indexedb api
The api contract is simple, initialize an object once then use that object as you would use any other plain object
View quoted note →