Re:Things I wish I knew about state management when I starte...
by bdcravens on Monday February 10, 2020 @03:34PM
(#22292972)
The issue seems with moving responsibilities that the server handles really well to the client (namely, state and session management). I think it's less a matter of Javascript-framework vs no framework, and more a matter of SPA vs. non-SPA
[ Parent
| on HN ]
Re:Things I wish I knew about state management when I starte...
by mands on Monday February 10, 2020 @04:29PM
(#22293578)
This hits the nail on the head - it's about SPA vs MPA. Component-based architectures are a proven and a win on FE for more complex interactions, but that doesn't necessitate an SPA. We had a large SPA with a REST API backend and were finding it really difficult to add more features to the FE due to the inherent complexity of the SPA.
We decided to split it into an MPA, adding React components to server-side rendered pages as needed (along with intercooler and stimulus when we don't need the power of React).
Things have become much simpler and quicker to develop, allowing us to focus on the user features instead. It's easy to forget how much you get for free from the browser and traditional HTTP/HTML client-server mechanics, along with the ease of having full access to your database and data model in your templates - and makes you wonder if going with an SPA first is throwing the baby out with the bathwater.