[thatswrong0]

Yep.

On top of that, the complexity of front end (for me, which is in a “real time” app) often comes down to providing a user experience that “feels good” while also accounting for the complexities of keeping things in sync with the backend(s). For example, I often want a user to be able to update a thing and I want that change to feel immediate, but if 1% of the time that errors out because of business logic reasons, I need to be able to undo the immediateness, restore the previous state, maybe reconcile the local state with the newer remote state, and then display the problem to the user.

Maybe I’m just doing things wrong but there’s just a lot of complexity related to that and I struggle compartmentalizing it in a maintainable way

[grebc]

It’s a pretty unconventional way to do it these days, but blow it all away and load the page fresh from the server.

Maintaining a consistent state is very difficult at the best of times. This obviously has implications for the backend, it needs to respond quickly and the page render in a decent time(minimal libraries).

[doix]

It really depends. For a "regular" website or blog, I agree. I think people over use complicated web frameworks to just serve what amounts to a mostly static page.

But the approach just doesn't work for things like Slack, Figma, Google docs. When you're trying to create an experience that's somewhat similar to a native application on the web, you need to start worrying about local state.

[rimunroe]

Personally, to the degree that I ever distinguish between “web apps” and just normal sites, one of the distinguishing features of web apps for me is whether forcing a page reload on the majority of interactions would be unacceptably clunky to most users.

Provided page reloads are fast, I think far more sites would be completely fine with just being sites and not rich client apps.