I have my issues with react but I don't think a different framework necessarily solves those issues since those issues are explicitly with how you need to handle state changes in JS and how "components" tie into that.
I haven't used it but something like Elixer Pheonix liveview[1] / .NET blazor[2] or skiplabs skip[3] or a well setup apollo client[4].
Nothing prevents you from building that abstraction on react, I don't know about Vue/Svelte.
The idea is though that there are models which should come from your backend, viewmodels which should be in your frontend code. And there should be no other state.
Whether a button is clicked or not has nothing to do with the backend. What the button does when it is clicked also has nothing to do with the backend. All that should theoretically happen when the button is clicked is you should decide what needs to happen. If a thingabob needs to be deleted from the viewmodel, no calls to.the backend. If that thingamabob is linked to the actual model then no frontend should change, the backend should change and a message that it has successded / failed should go to the frontend.
It's when you bring optimistic updates and eventual consistency etc in, then your frontend code becomes absolutely chaotic. You make it a distributed computing problem but then instead of message passing and actors which is a known good way to handle distributed computing you try to synchronise state.
Is it more abstract? Is the state model simpler?
I have my issues with react but I don't think a different framework necessarily solves those issues since those issues are explicitly with how you need to handle state changes in JS and how "components" tie into that.
I haven't used it but something like Elixer Pheonix liveview[1] / .NET blazor[2] or skiplabs skip[3] or a well setup apollo client[4].
Nothing prevents you from building that abstraction on react, I don't know about Vue/Svelte.
The idea is though that there are models which should come from your backend, viewmodels which should be in your frontend code. And there should be no other state.
Whether a button is clicked or not has nothing to do with the backend. What the button does when it is clicked also has nothing to do with the backend. All that should theoretically happen when the button is clicked is you should decide what needs to happen. If a thingabob needs to be deleted from the viewmodel, no calls to.the backend. If that thingamabob is linked to the actual model then no frontend should change, the backend should change and a message that it has successded / failed should go to the frontend.
It's when you bring optimistic updates and eventual consistency etc in, then your frontend code becomes absolutely chaotic. You make it a distributed computing problem but then instead of message passing and actors which is a known good way to handle distributed computing you try to synchronise state.
1. https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Auth.html#modul...
2. https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
3. https://skiplabs.io/
4. https://www.apollographql.com/docs/react