Trying to make web applications with it is another story though. The lack of any state management is a nightmare, hence declarative frameworks/libraries such as React/Angular(JS)/Vue/Svelte etc. etc. came along.
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.
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 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.
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.
jQuery just changes the DOM. It gets very difficult to keep the DOM in sync with the JavaScript backed data when there’s multiple moving parts.
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.
le sigh
*And you BETTER be using the minified version for production.
Good or bad depending on context.
Placing the blame on him when you were the one being hostile is hostile.