16 ms·

I've never worked on a project that could be "all in" on client side state. To be all in there means your application doesn't need the network at all except as

I've never worked on a project that could be "all in" on client side state. To be all in there means your application doesn't need the network at all except as a method to distribute your application. One step away from that would be something that is completely client authoritative - I've also never worked on a project like that. Note that even if your code has zero Javascript, you can still have state mixed between client and server: instead of living in Javascript, it lives in the html, oftentimes as values in form elements. Even though the html is generated on the server, it still lives in the client, ready for the client to do things with it - such as submit a form with information that is 8 hours out of date. There are obviously ways around this, but it's still something one should keep in mind. Live update via websockets can kinda get around this. As long as there are no bugs and all state is properly transmitted and processed in a deterministic order. But it's still effectively a synchronization process and stuff can go wrong.

singingboyo 5y ago
You're technically correct (the best kind!) but in practice one can largely ignore server state in some applications. I've got a side project where the data is stored server side. In practice, that server side data might as well be a saved file on the clients hard drive. Is it "all in" on client state? Not really. Do I ever need to worry much about synchronization? Also no. The synchronization is just "send it to the server when it changes, put an error bar up if that fails". Pretty simple. It's a bit network heavy, but in this case there are other, heavier parts of the app. There are options if data size ever does become an issue - for now it's not. Incidentally, I feel like this is where something like MongoDB really is a decent choice. The client would probably just preload the data anyway if it were normalized and in Postgres somewhere. API serves out JSON. Why not just... load the JSON out of the DB?
- em-bee 5y ago
  that's pretty much how i build all my websites. not with mongodb but another reusable generic CRUD backend. it's not much more network heavy than a static or serverside rendered site and the server doesn't need to keep any state other than the data itself. any custom state that the client wants to store on the server is just saved as additional server data.

singingboyo 5y ago

You're technically correct (the best kind!) but in practice one can largely ignore server state in some applications. I've got a side project where the data is stored server side. In practice, that server side data might as well be a saved file on the clients hard drive. Is it "all in" on client state? Not really. Do I ever need to worry much about synchronization? Also no. The synchronization is just "send it to the server when it changes, put an error bar up if that fails". Pretty simple. It's a bit network heavy, but in this case there are other, heavier parts of the app. There are options if data size ever does become an issue - for now it's not. Incidentally, I feel like this is where something like MongoDB really is a decent choice. The client would probably just preload the data anyway if it were normalized and in Postgres somewhere. API serves out JSON. Why not just... load the JSON out of the DB?

em-bee 5y ago
that's pretty much how i build all my websites. not with mongodb but another reusable generic CRUD backend. it's not much more network heavy than a static or serverside rendered site and the server doesn't need to keep any state other than the data itself. any custom state that the client wants to store on the server is just saved as additional server data.