I agree, modern browsers, CSS and JS can do so much now.
However, the frontend build systems are often complex to do complex state management. Sure, it's possible to reimplement it all and accidentally end up rewriting your own vanilla JS frontend framework, but beyond a point, that's equally as unfun as modern webdev.
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.
Now, having designed, built and run systems from on-prem, through VPS & VMs onto serverless and static site stuff, doing it the old way again just feels better overall. Maybe it's nostalgia.
But then I feel the reason why we moved away from doing it the old way was because the complexity of the applications needed more efficient ways to make use of relatively limited bandwidth, storage and compute resources at the time. Now these things are all commoditised, and my home desktop and internet connection now has probably the same capabilities as a small datacentre back then... the dreamer in me wants to believe there's no reason why we can't all go back to the old ways of doing it now.
Big part of why FE system are so complex now is because we moved a lot from BE to FE, especially state management. I dont think it is possible to get back to session cookies and keep the "infinite" horizontal scaling that modern BE have.
Yeah, that's what I was referring to mainly - frontend frameworks to help manage complex state in the browser. If you want complex state in the browser, using vanilla JS to do the same clientside state and rendering becomes tedious: it's easier and more fun to shift it back to the backend.
Not sure I fully understand the second bit. Given how much more powerful servers are now (both physical and abstracted) doesn't that vertical scaling mean horizontal scaling is less necessary? If horizontal scaling is necessary, depending on where in the stack you're scaling, the global consistency offered by modern cloud data stores make it more efficient than ever for lots of servers to exchange a session cookie for state and return fully rendered HTML.
I think it's more nuanced than that. The original React model of UI = f(state) is pretty simple and solved the state management issue. Building your UI with function composition isn't a massive jump in complexity
..but then they kept adding. And adding. And adding. And adding.. and now where are we? Death by a thousand cuts. 10x the complexity for an additional 7% benefit
React is pretty barebones, they keep adding stuff because how ugly the original one looks like and how outdated feels like compared to "modern" ones like Vue, Svelte, etc...
You don’t have to use all that other stuff. React works best if you prioritize function composition. So much of the ecosystem is there to support the people that don’t know what composition is.
> 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.
You can do state management easily enough with variables and a rerender function. React et al give you granular DOM updates for performance, but for a simple app it doesn't really matter.