4 ms·
State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Cod
by johnfn 2y ago
State management is absolutely a real front end concern. That's what you're going to be spending a lot of your time on; you better make sure you do it well. Code style is roughly a solved problem thanks to Prettier, as is build steps with Vite. And I don't know what you mean that "framework madness" is a fashion concern. You have to pick a framework, you can't just avoid that part.
- austin-cheney 2y agoYes, it is a real concern, but its supremely trivial to solve for. Frameworks make this into chaos madness because frameworks have to solve for both the goal of state management in addition to their own divisible component concerns that come and go with user interactions.
- johnfn 2y agoI'd be very interested to hear how state management is supremely trivial to solve for.
- austin-cheney 2y agoUmmm, no. I have been through this before and its always a paradox. The paradox works like this: If you were capable of writing your own software the triviality of state management becomes self evident. If you are not capable of writing your own software, such as full eternal reliance on some tool set or framework, then the answer doesn't matter.
- johnfn 2y agoI've written my own software, both with and without state management frameworks. To be honest, I didn't find state management to be particularly "trivial", except when I worked on trivial applications.
- skydhash 2y ago> State management is absolutely a real front end concern That’s because most SPAs are duplicating backend logic.
- johnfn 2y agoA 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 agothanks, I'll reuse that one!
- ravenstine 2y agoThey 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 agoREST 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).