My main issue with putting state in the frontend is that you introduced sync points, which is where, like, 90% of the bugs happen.
Take form input and validation. Great, let's write out the validation on the frontend. But that doesn't mean much. We need to sync it.
Okay... So let's just write the validation, again, on the backend. Hope it's the same validation. It never is, so we just introduced a whole class of bugs around that.
Or just take a look at routing. Okay, let's route on the frontend. But what about access control? Okay, let's do a little routing logic on the backend too. Oh and now we've run into the same problem.
When you do rich frontend and backend, you always have a minimum of two application states. You have two apps. You cannot get rid of the backend state, it's non-negotiable.
So you have to keep them in sync, or more accurately, try to keep them in sync.
you have to do the same on the server side and your database, if you have one. the API is just data too. you don't keep all your application state in you database, do you?
i don't know what kind of application you have in mind, but in mine the frontend state and the backend state are entirely different things. the only thing that needs to be kept in sync is the data itself. and that's easier than the whole frontend state which is a lot more complex. in most cases you treat the backend like a database itself. there is n additional state to be kept in the backend, than what goes into the database. at least with all the applications i ever built. i am sure there are other applications that are more complex, and i may change my mind when i get to work on one, but i believe most applications are CRUD, and complex UI state is only in the fronted, data state in the backend/database,
my keyboard swallows keys, to remove ambiguity, i meant to say "there is no additional state to be kept in the backend"