3 ms·

Trying to synchronize state between client & server is a cursed problem. You can sidestep it altogether if you make mild UX sacrifices and revert to something

Trying to synchronize state between client & server is a cursed problem. You can sidestep it altogether if you make mild UX sacrifices and revert to something more akin to the PHP/SSR model. SPA is nice, but multipart form posts still work. Just the tiniest amount of javascript can smooth out most of the remaining rough edges. Our latest web products utilize the following client-side state: 3rd party IdP claims for auth 1st party session id in query args The current document For the first item, I genuinely don't even know where this is stored. It's Microsoft's problem, not ours. All other state lives on the server. We treat the client more or less like a dumb terminal that punches <form>s all day. We don't even use first party cookies or local storage to get the job done. This dramatically improved our development experience for iOS/Safari targets. So, I would ask this: What is the actual experience you are trying to offer, and why does it justify decoupling of client & server state?

threatofrain 3y ago
It's a very common trend for consumer-facing GUI's to have optimistic rendering, and if you're doing that then you're juggling client/server state. I still see spinning loaders here and then but they're generally for initial content load; e.g., does Gmail make you wait when you archive an email?
- _heimdall 3y ago
  Not the GP, but I would include optimistic rendering on the list of common patterns that really are a bad idea. Optimistic rendering means your frontend and backend are tightly coupled, error recovery and synchronization is much more complex, and you are locked into (likely heavy) frontend rendering patterns that add even more complexity and coupling. We've spent well over a decade trying to avoid the fact that frontend actions require backend logic to complete. Its a losing battle that's just made worse by trying to paper over it. Edit to clarify: this isn't a direct comment on the OP tool. I haven't used this tool directly but having a hunch it does solve some important use cases for common patterns.
  - pas 3y ago
    the real UX goal is to minimize data loss (ie. provide the ability to resume whatever the user was doing, from a point that's as recent as possible), and for this it becomes necessary to provide "auto-save" at that point there's already a diverging state problem, even if it's saved to localStorage (but obviously it's much better to save it on the server) it's absolutely ridiculous that we spent the last 10+ years simply reinventing the same wheel (all low-level tools, Angular, React, Vue, rxjs, hooks, signals, whatever, etc), without providing the useful composable primitives for the hard problems. and now there's yet one more thing on the frontend, SQLite. okay, there's a sync thing too. it's not like we didn't try it with that adorable DB (RethinkDB).
    - _heimdall 3y ago
      > the real UX goal is to minimize data loss Can't say I've been asked to build optimistic updates for that reason, but the irony there is pretty rich if that's the UX goal you've seen it used for. In my experience optimistic rendering actually creates more data loss risk than it solves. Caching layers are involved, state is duplicated, and routing comes into question as users could leave the page before a failure state is returned.
      - pas 3y ago
        No, I mean in general, that's the hard problem. The main goal is that the user wants to do something, but there's an instrumental goal that the system has to be resilient to typical real world problems, otherwise the users will have a bad time. For example the user wants to interact with the service, order something, check for new messages or send one. On the happy path things are trivial, easy, synchronous, even quite resilient. There's not much complexity to manage on "no new message" or "add to cart, yes, buy with saved card, ship to saved address, k thx bye", if the browser or server crashes, or there's a network error, the interaction is short, easy to retry, problems are not hidden (quasi instant feedback) But as the total interaction time increases, as the state the user would need to reproduce grows (adding new card, shipping/billing address, adding a lot of stuff into the card, writing a long message) the need for partial state sync arises.
- pas 3y ago
  gmail makes you wait when you are deleting spam (ie. selecting a ~100 messages and clicking delete permanently, or how it's called, and it's surprisingly slow)
obeavs 3y ago
ElectricSQL has made massive strides towards solving this fwiw. Write sqllite in client, guarantee sync to postgres. See: https://news.ycombinator.com/item?id=37584049 https://news.ycombinator.com/item?id=37584049

threatofrain 3y ago

It's a very common trend for consumer-facing GUI's to have optimistic rendering, and if you're doing that then you're juggling client/server state. I still see spinning loaders here and then but they're generally for initial content load; e.g., does Gmail make you wait when you archive an email?

_heimdall 3y ago
Not the GP, but I would include optimistic rendering on the list of common patterns that really are a bad idea. Optimistic rendering means your frontend and backend are tightly coupled, error recovery and synchronization is much more complex, and you are locked into (likely heavy) frontend rendering patterns that add even more complexity and coupling. We've spent well over a decade trying to avoid the fact that frontend actions require backend logic to complete. Its a losing battle that's just made worse by trying to paper over it. Edit to clarify: this isn't a direct comment on the OP tool. I haven't used this tool directly but having a hunch it does solve some important use cases for common patterns.
- pas 3y ago
  the real UX goal is to minimize data loss (ie. provide the ability to resume whatever the user was doing, from a point that's as recent as possible), and for this it becomes necessary to provide "auto-save" at that point there's already a diverging state problem, even if it's saved to localStorage (but obviously it's much better to save it on the server) it's absolutely ridiculous that we spent the last 10+ years simply reinventing the same wheel (all low-level tools, Angular, React, Vue, rxjs, hooks, signals, whatever, etc), without providing the useful composable primitives for the hard problems. and now there's yet one more thing on the frontend, SQLite. okay, there's a sync thing too. it's not like we didn't try it with that adorable DB (RethinkDB).
  - _heimdall 3y ago
    > the real UX goal is to minimize data loss Can't say I've been asked to build optimistic updates for that reason, but the irony there is pretty rich if that's the UX goal you've seen it used for. In my experience optimistic rendering actually creates more data loss risk than it solves. Caching layers are involved, state is duplicated, and routing comes into question as users could leave the page before a failure state is returned.
    - pas 3y ago
      No, I mean in general, that's the hard problem. The main goal is that the user wants to do something, but there's an instrumental goal that the system has to be resilient to typical real world problems, otherwise the users will have a bad time. For example the user wants to interact with the service, order something, check for new messages or send one. On the happy path things are trivial, easy, synchronous, even quite resilient. There's not much complexity to manage on "no new message" or "add to cart, yes, buy with saved card, ship to saved address, k thx bye", if the browser or server crashes, or there's a network error, the interaction is short, easy to retry, problems are not hidden (quasi instant feedback) But as the total interaction time increases, as the state the user would need to reproduce grows (adding new card, shipping/billing address, adding a lot of stuff into the card, writing a long message) the need for partial state sync arises.
pas 3y ago
gmail makes you wait when you are deleting spam (ie. selecting a ~100 messages and clicking delete permanently, or how it's called, and it's surprisingly slow)

obeavs 3y ago

ElectricSQL has made massive strides towards solving this fwiw. Write sqllite in client, guarantee sync to postgres. See: https://news.ycombinator.com/item?id=37584049 https://news.ycombinator.com/item?id=37584049