> Is that complexity necessary or artificially inflated?
Totally unnecessary in 99% of cases. There are outliers where this front-end/back-end state division madness makes sense (i.e. gigantic apps managed by gigantic teams), but most web properties are not this big.
To be clear - the division of state between client & server is where almost everyone is struggling. State management is usually the hardest part of any complex app. When you have 2 piles of it to worry about, you make life much harder.
In my view, the happy-path solution has been out there for a while. Frameworks that utilize a web socket (or similar bi-directional messaging abstraction) to directly relay user events & DOM updates. This can eliminate nearly 100% of client-side state. If you keep the logical representation of all clients' views server-side, you will have a much easier time keeping things synchronized (because there will be nothing to sync except the session cookie).
I started this journey with Blazor (server-side), which really helped to solidify the concept and its pros/cons. Now, I have a custom framework that achieves approximately the same outcome, but with much better alignment to my problem domain & requirements. I add my middleware and work directly with HttpContext these days. Life is so much easier when you don't have to deal with layers upon layers of opinionated indirections.
Totally unnecessary in 99% of cases. There are outliers where this front-end/back-end state division madness makes sense (i.e. gigantic apps managed by gigantic teams), but most web properties are not this big.
To be clear - the division of state between client & server is where almost everyone is struggling. State management is usually the hardest part of any complex app. When you have 2 piles of it to worry about, you make life much harder.
In my view, the happy-path solution has been out there for a while. Frameworks that utilize a web socket (or similar bi-directional messaging abstraction) to directly relay user events & DOM updates. This can eliminate nearly 100% of client-side state. If you keep the logical representation of all clients' views server-side, you will have a much easier time keeping things synchronized (because there will be nothing to sync except the session cookie).
I started this journey with Blazor (server-side), which really helped to solidify the concept and its pros/cons. Now, I have a custom framework that achieves approximately the same outcome, but with much better alignment to my problem domain & requirements. I add my middleware and work directly with HttpContext these days. Life is so much easier when you don't have to deal with layers upon layers of opinionated indirections.