4 ms·

> State management is absolutely a real front end concern That’s because most SPAs are duplicating backend logic.

johnfn 2y ago
A certain subset of SPAs need to duplicate backend logic because they necessarily and unavoidably have local state. For instance, optimistic updates require some redundancy with backend logic.
greenchair 2y ago
thanks, I'll reuse that one!
ravenstine 2y ago
They often do that because of the REST/CRUD chokehold where the backend does a bunch of stuff, squeezes the resulting data into extremely basic primitive actions (e.g. GET, POST, PATCH, DELETE), forcing the frontend to recreate a complex state all over again. GraphQL tries to solve this, and usually frontends that rely on that avoid a lot of that duplication of the backend, but devs sometimes manage to scream up even that. If we kill REST, a lot of the complexity around frontends would be reduced significantly. You don't even need GraphQL or RPC protocols to do that.
- skydhash 2y ago
  REST is not a browser concept, it’s just a pattern. There’s no need to “kill” it. The HTTP protocol is more than enough to interact with a server that store resources and a client that display them. If you’re sure you need another set of verbs and nouns, use http as a tunnel.
  - ravenstine 2y ago
    > REST is not a browser concept I didn't say that it was specifically. REST is still a convention that is usually tied to and influenced by HTTP and its methods. It doesn't necessarily have to be that way exactly, but that's how many web applications are typically written. > There’s no need to “kill” it. We don't necessarily need it around either. > If you’re sure you need another set of verbs and nouns, use http as a tunnel. That is somewhat along the lines of what I'm suggesting. REST is not necessarily better than an API that just takes POST requests in a way that serves the application's needs directly rather than some abstract standard that homogenizes data in ways that require extra work to be done. For some odd reason, many frontend-oriented developers look at me like I've got bugs crawling out of my ears when I say this, yet the idea of allowing the server to do the bulk of the work is both old and resurging in popularity (e.g. Hotwire, LiveView, HTMX).
xboxnolifes 2y ago
Yes, because in the scenarios where a SPA is appropriate, round-tripping on every state change is terrible UX.
- skydhash 2y ago
  In such scenarios, there's no need for round tripping because the state are different. But in every SPA that should be an MPA, it's always state duplication.

A certain subset of SPAs need to duplicate backend logic because they necessarily and unavoidably have local state. For instance, optimistic updates require some redundancy with backend logic.

greenchair 2y ago

thanks, I'll reuse that one!

ravenstine 2y ago

They often do that because of the REST/CRUD chokehold where the backend does a bunch of stuff, squeezes the resulting data into extremely basic primitive actions (e.g. GET, POST, PATCH, DELETE), forcing the frontend to recreate a complex state all over again. GraphQL tries to solve this, and usually frontends that rely on that avoid a lot of that duplication of the backend, but devs sometimes manage to scream up even that. If we kill REST, a lot of the complexity around frontends would be reduced significantly. You don't even need GraphQL or RPC protocols to do that.

skydhash 2y ago
REST is not a browser concept, it’s just a pattern. There’s no need to “kill” it. The HTTP protocol is more than enough to interact with a server that store resources and a client that display them. If you’re sure you need another set of verbs and nouns, use http as a tunnel.
- ravenstine 2y ago
  > REST is not a browser concept I didn't say that it was specifically. REST is still a convention that is usually tied to and influenced by HTTP and its methods. It doesn't necessarily have to be that way exactly, but that's how many web applications are typically written. > There’s no need to “kill” it. We don't necessarily need it around either. > If you’re sure you need another set of verbs and nouns, use http as a tunnel. That is somewhat along the lines of what I'm suggesting. REST is not necessarily better than an API that just takes POST requests in a way that serves the application's needs directly rather than some abstract standard that homogenizes data in ways that require extra work to be done. For some odd reason, many frontend-oriented developers look at me like I've got bugs crawling out of my ears when I say this, yet the idea of allowing the server to do the bulk of the work is both old and resurging in popularity (e.g. Hotwire, LiveView, HTMX).

xboxnolifes 2y ago

Yes, because in the scenarios where a SPA is appropriate, round-tripping on every state change is terrible UX.

skydhash 2y ago
In such scenarios, there's no need for round tripping because the state are different. But in every SPA that should be an MPA, it's always state duplication.