Unhelpful advice. Typical programmer up his own ass bullshit really. Oh that ways not good. Well what's good? I don't know, just not that. Look at how many clowns criticize jQuery these days as an example of garbage software.
jQuery isn't garbage as per se. It's a great library for directly querying & manipulating the DOM.
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.
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.
I think jQuery got a bad rap because so many script kiddies would drop the entire damn framework into a page when they just didn't feel like writing a standard selector to do a mobile menu.
I mean, if all you're doing is showing and hiding a mobile menu, you can do that in a really expanded form in like 5 lines of vanilla JS, and not have your user download 90 KB* of crap.
*And you BETTER be using the minified version for production.
90 KB is probably bad for a marketing page, but it’s nothing for a B2B or internal use app, particularly when the second use is just the “you already have it” HTTP header response.
I don't disagree, but when so many public websites are unloading megabytes of Javascript for simple tasks, it feels like that attitude is the core problem. I'm not opposed to using frameworks when they're needed, I just have a problem with people using them to shorten up already short and very easy code because they can't be bothered to Google for a few minutes.
I'm not being hostile, I apologize if you took it that way. I'm just making a point about how so many dev's claim to have the right answer until you need to rely on them to get something done. Projects turn to a mess mostly due to things one single person cannot control. I don't know a single person, including myself, who've thought that their code didn't look like shit 6 months to a year down the road. I think we always get better and we'll always criticize what we don't know and understand. This includes mountains of other peoples code (garbage or not).
He did just apologize in case that person perceived something hostile when it was not meant to be hostile. He should not have apologized it seems. Damned if you do, damned if you do not.
