explaining coherence on a call, this feedback:
so basic idea, is: when something changes, instead of sending the data for that change to rerender that interface, just send a signal that that interface has probably changed
- signal - it's easy to recognise when something has changed, but figuring out all the data to send is not as easy.
- also, the client might not actually want the data right now, (for example, app is open in background, not foreground)
- it's okay to sometimes be wrong, a signal about something that hasn't actually changed just means that view is rerendered, but stays the same.
side by side comparison between lazy signals and eagre data, across various
what about updates applied to the front end first?
- you could maintain the architecture via a service worker, which buffers posts, then sends them to server in background.
- but most applications that update in real time don't actually update very often.
instead, optimize for not sending data that's not needed (be more lazy) because using too much resources has more positive impact on user experience than being notified slightly faster, but using more memory and being slow all the rest of the time.
explaining coherence on a call, this feedback:
so basic idea, is: when something changes, instead of sending the data for that change to rerender that interface, just send a signal that that interface has probably changed
side by side comparison between lazy signals and eagre data, across various
what about updates applied to the front end first?
instead, optimize for not sending data that's not needed (be more lazy) because using too much resources has more positive impact on user experience than being notified slightly faster, but using more memory and being slow all the rest of the time.