> It's not hard to shift the state management though, and when I find myself sat with a nice architecture that's formed without a complex frontend system, and with some really simple, uncluttered backend that could probably serve millions of requests a day from a homeserver and internet connection.... it gives me a profound feeling. It's a satisfying and familiar feeling from webdev I enjoyed around 2 decades ago as a teen. It feels like the old way of doing it.
I recall working on systems where the frontend and backend lacked clear separation, such as through an API layer, and there were no defined contracts outlining these boundaries between different teams or disciplines. This often led to significant challenges and disorganization, necessitating numerous compromises, not just in UX and UI.
Such issues typically arise in projects involving many people and disciplines. Fortunately, libraries like React and frameworks like Next.js have significantly reduced this chaos by facilitating the development of a decoupled frontend and backend.
This was 10 or 15 years ago. Now, with a decoupled front-end and middleware/backend, it's much easier to refactor or even replace services and features. Additionally, it's much easier to integrate new teams and technologies.
That delineation is all but gone in some apps. Elixir liveview for instance, has not concept of front or backend. It's all socket, so there's no break.
I agreed it makes it harder in places. Like when I (as a be dev) have to write JS hooks, or the JS dev's on the team have to interact with the database.
I find I'd rather code in a RESTfull code base than a socket system. I miss the lines.