6 ms·

They touch on it at the end but I think it is under-appreciated ... the big benefit of a SPA is continuity of client side state. I don't actually care whether i

by zmmmmm 4y ago

They touch on it at the end but I think it is under-appreciated ... the big benefit of a SPA is continuity of client side state. I don't actually care whether it's one page or ten but it does simplify things enormously that I can maintain a single model object and not have to persist it in and out of local storage or even worse have all the complex UI state replicated on the server side to maintain continuity, just because the user clicked a button or something. Especially with reactive frameworks where updating the model automatically triggers re-rendering of the UI everywhere it needs to, a whole piece of complexity in your architecture just goes away.

my69thaccount 4y ago
SPAs suck at client side state, they barely work with the back button or scroll bar and if they do its because its reimplemented in JS.
- nighthawk454 4y ago
  Not browser state, but application state. Lot more boilerplate and glue to do that on server side and ferry it back and forth.
  - infogulch 4y ago
    But the application is embedded in a browser. Are you saying it's fine to bin all that UI state the moment the user performs a totally normal interaction with their browser? Accidentally hitting back or refresh in a complex SPA and losing the state of the application is one of the most frustrating experiences on the web, right behind trying to hit back or refresh intentionally and being blocked because the SPA overrides those functions.
    - nighthawk454 4y ago
      No? I simply clarified which state op was referring to. The state of the browser is separate to what's being discussed. SPA's can be good at some state and not others.
theonething 4y ago
I actually see having to manage client side state as one of SPAs' greatest downsides. You're literally doubling the complexity of your application. Now you have to maintain state on both the server and the client and it becomes a great effort to make sure they don't get out of sync. The way I see it, the state of an application resides in the server, more specifically, the database. Let's keep it there.
- bowsamic 4y ago
  If you have a UI, you have UI state, so you’ll have to synchronise it somehow
  - theonething 4y ago
    If your UI is rendered on the server, then your UI state remains on the server. It just ferries that state to the client. There's no synchronization involved because it's synchronized by default.
    - bowsamic 4y ago
      So your proposal is that whenever literally any ui interaction is performed the server is notified and the page is reloaded with the server state?
      - theonething 4y ago
        That's how traditional SSR applications work. The new way is html over the wire e.g. Hotwire, Liveview, htmx. So instead of the page being reloaded, the section of the UI that needs to updated is rendered on the server and sent over via websocket.
        bowsamic 4y ago
        No they don’t, they use web forms, which are a local UI state that gets bundled up and sent when the user presses a submit button. They do not refresh on every single UI change

by zmmmmm 4y ago

my69thaccount 4y ago

SPAs suck at client side state, they barely work with the back button or scroll bar and if they do its because its reimplemented in JS.

nighthawk454 4y ago
Not browser state, but application state. Lot more boilerplate and glue to do that on server side and ferry it back and forth.
- infogulch 4y ago
  But the application is embedded in a browser. Are you saying it's fine to bin all that UI state the moment the user performs a totally normal interaction with their browser? Accidentally hitting back or refresh in a complex SPA and losing the state of the application is one of the most frustrating experiences on the web, right behind trying to hit back or refresh intentionally and being blocked because the SPA overrides those functions.
  - nighthawk454 4y ago
    No? I simply clarified which state op was referring to. The state of the browser is separate to what's being discussed. SPA's can be good at some state and not others.

theonething 4y ago

I actually see having to manage client side state as one of SPAs' greatest downsides. You're literally doubling the complexity of your application. Now you have to maintain state on both the server and the client and it becomes a great effort to make sure they don't get out of sync. The way I see it, the state of an application resides in the server, more specifically, the database. Let's keep it there.

bowsamic 4y ago
If you have a UI, you have UI state, so you’ll have to synchronise it somehow
- theonething 4y ago
  If your UI is rendered on the server, then your UI state remains on the server. It just ferries that state to the client. There's no synchronization involved because it's synchronized by default.
  - bowsamic 4y ago
    So your proposal is that whenever literally any ui interaction is performed the server is notified and the page is reloaded with the server state?
    - theonething 4y ago
      That's how traditional SSR applications work. The new way is html over the wire e.g. Hotwire, Liveview, htmx. So instead of the page being reloaded, the section of the UI that needs to updated is rendered on the server and sent over via websocket.
      - bowsamic 4y ago
        No they don’t, they use web forms, which are a local UI state that gets bundled up and sent when the user presses a submit button. They do not refresh on every single UI change