What makes the lack of state management a nightmare in the javascript world, but a complete non-issue when doing .NET or Qt apps?
As someone who started with desktop apps and then moved into web dev, I never really understood why Javascript developers wanted a library to help them manage state.
All the state management stuff seems to be tied up in (=synonymous with) attempts to purify JS frameworks and codebases, as in "purely functional". It's... kinda silly and far removed from either the problem at hand, or the strengths of Javascript (such as they are) much of the time.
Meanwhile objects representing various parts of the view, and plenty of models that don't look much like "modern" JS state management, remain the norm elsewhere, and the sky is not falling. I do not know what to make of it. I go along with it when in that sort of company—when in Rome, and all that—but the evangelism can be pretty funny.
Anyway a bunch of the stuff isn't half as special as you'd think reading about it through the usual channels. Redux? A data cache and a so-so local event bus with somewhat awkward semantics and a few really bad terminology choices thrown in. Whee. There's your "state management". Not that it's useless, but you'd swear it's black magic reading all the blog posts about it.
The main benefit of purely functional systems is function composition. The ability to build entire programs through the composition of function primitives. Composition without dependencies.
The problem with javascript is that this concept is entirely lost on react developers. Due to the untyped nature of javascript and it's close linkage with html. HTML is made up of dependent components and this essentially puts dependency injection into javascript leading to JAVA like issues that the functional paradigm was suppose to solve.
> I never really understood why Javascript developers wanted a library to help them manage state
The reason is rooted in how browsers work.
In native software you can "just" render your data structures directly to the screen. In the browser, barring webgl, you can't render your data structures directly to the screen, instead, you're forced to interact with an imperative browser API to individually manage bespoke UI widgets that store their own state internally and can't understand nor access any of the data structures defined for your business logic. The only option left is to manually update the internal state of the browser UI widgets whenever you update the internal state of your application. Manually keeping the two states in snyc is a real pain, highly bug prone, and a maintenance nightmare. The front-end browser frameworks came along as a way to "auto-sync" the business logic state with the browser ui state.
That's the same way you work with literally every other UI framework (except the immediate-mode GUIs popular in gamedev), complete with the built-in event loop that's hidden from you. Web isn't special here, except that no other framework I've seen allows you to modify the UI by programmatically editing the serialized text description of it.
> Again I don't understand this argument. What's difficult about it? People have been doing it with win forms for well over a decade now.
And yet it's recognized as a problem there, too, and one of the more recent solutions is state management libraries inspired by those used in Web apps, e.g., there are fairly direct copies/adaptations of React and Redux for .NET specifically to address this issue.
What makes the lack of state management a nightmare in the javascript world, but a complete non-issue when doing .NET or Qt apps?
As someone who started with desktop apps and then moved into web dev, I never really understood why Javascript developers wanted a library to help them manage state.