Not gonna comment on most of this, as I'm right there with you. Web development is a gigantic shit sandwich. But I have to at least respond to this:
> I'm not even talking about the fact that everything has to be stateless, in fact I develop desktop apps as stateless even driven UIs as well,
No, you do not. UIs are state machines (not like state machines, they actually are state machines). It is impossible to have a stateless interactive UI. If it is stateless, it might be a web page or document, but it is not a UI.
Any attempt to make a "stateless" UI will fail because of this impossibility. What many half-baked frameworks will attempt to do is make them as stateless as possible, which is a recipe for disaster, as they can't actually get rid of the state, they can only move it to some location where it wasn't designed to store state (Routes? Cookies?), or to some location where the semantics and comprehensibility have been compromised. In fact, this statelessness is precisely one of the major problems with web programming...you're trying to bolt something inherently stateful onto a format that was designed for statelessness (HTML was created for documents, not apps).
Programmers in general, and UI programmers in particular, need to get over their fetish for statelessness. Sure, modeling a stateless problem with stateful code is ridiculous, but if you try to model a stateful problem with stateless code you are going to have a much worse time. Modeling state is hard...don't make it harder by pretending it doesn't exist.
> I'm not even talking about the fact that everything has to be stateless, in fact I develop desktop apps as stateless even driven UIs as well,
No, you do not. UIs are state machines (not like state machines, they actually are state machines). It is impossible to have a stateless interactive UI. If it is stateless, it might be a web page or document, but it is not a UI.
Any attempt to make a "stateless" UI will fail because of this impossibility. What many half-baked frameworks will attempt to do is make them as stateless as possible, which is a recipe for disaster, as they can't actually get rid of the state, they can only move it to some location where it wasn't designed to store state (Routes? Cookies?), or to some location where the semantics and comprehensibility have been compromised. In fact, this statelessness is precisely one of the major problems with web programming...you're trying to bolt something inherently stateful onto a format that was designed for statelessness (HTML was created for documents, not apps).
Programmers in general, and UI programmers in particular, need to get over their fetish for statelessness. Sure, modeling a stateless problem with stateful code is ridiculous, but if you try to model a stateful problem with stateless code you are going to have a much worse time. Modeling state is hard...don't make it harder by pretending it doesn't exist.