> In my opinion doing all of the UI interaction on the client is easier to reason about and simplifies state management.
Is this even true in most cases? You almost always have some state that needs to be in both places. The more you choose strategies to optimize for client-side development and treat the backend as just a store for "blobs" of data, the more problems you have given enough scale, requirements, or just the passage of time.
What you state is correct for a subset of applications, but it's not universally applicable. With enough time and experience you'll likely understand the limitations. I'm not going to keep arguing with you because your subset can get you very far, and it's probably the right thing to do for your needs.
> I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities
Can you elaborate on the complexities? The desktop (as in Win32, Qt, etc.) and the web are on different ends of a spectrum. With JavaScript frameworks we have an in-between. In many ways you can put native mobile development in the desktop bucket because they are effectively have similar constraints, although some of the ideas/tools are a more modern implementation.
When you try and build abstractions to make the web feel more and more like desktop you expose the limitations of web development. The web will support more and more application features, but progress is naturally going to be slow around the maturation of these features than if you had gone with full desktop. What's interesting is that the web keeps pace enough that it never gets eliminated from the race. This is very important part of web and why people keep betting on it.
Is this even true in most cases? You almost always have some state that needs to be in both places. The more you choose strategies to optimize for client-side development and treat the backend as just a store for "blobs" of data, the more problems you have given enough scale, requirements, or just the passage of time.
What you state is correct for a subset of applications, but it's not universally applicable. With enough time and experience you'll likely understand the limitations. I'm not going to keep arguing with you because your subset can get you very far, and it's probably the right thing to do for your needs.
> I am not arguing that the current state of client side is where we want to be, but in a lot of ways it beats where we have been, and that is how we got here. It will never compete with desktop development because the web just injects a while host of complexities
Can you elaborate on the complexities? The desktop (as in Win32, Qt, etc.) and the web are on different ends of a spectrum. With JavaScript frameworks we have an in-between. In many ways you can put native mobile development in the desktop bucket because they are effectively have similar constraints, although some of the ideas/tools are a more modern implementation.
When you try and build abstractions to make the web feel more and more like desktop you expose the limitations of web development. The web will support more and more application features, but progress is naturally going to be slow around the maturation of these features than if you had gone with full desktop. What's interesting is that the web keeps pace enough that it never gets eliminated from the race. This is very important part of web and why people keep betting on it.