[bufferoverflow]

jQuery is not awesome.

It was awesome 15 years ago. Now it's completely outdated. It's very hard to reason about DOM that can be manually changed by any random piece of code. That's why declarative solutions like React/Vue/Svelte are so much better.

[rjbwork]

>It's very hard to reason about DOM

I don't mean to be overly snarky here, but as someone who's just totally out of their depth in modern web UI - is that why people like these frameworks? Because they're very easy to reason about? I've generally found them to be mountains and mountains of boilerplate and spaghetti, but I really do not have a wide base of experience to pull from on this topic.

[Capricorn2481]

I started with Jquery, I learned React. I prefer React.

React complexity is often conflated with things like Next JS or other SPA solutions. React was originally meant to be a library for building small components that you drop into an otherwise static websites. But people usually don't talk about React unless they're talking about whole sites being in React. For that reason, I think its complexity is exaggerated.

More importantly, what the commenter is referring to is the fact that you are encouraged to write Jquery code that can break if you decide to move a div or change a class name. The workflow of CSS selectors is fine for small apps, but can lead to hard to track bugs down the road. It can be avoided if you make a lot of unique IDs. But otherwise you're screwed. There's no scoping. You technically have to read every piece of Jquery code before changing any other code, html, or css, because you could break half the site depending on what people were depending on. There's no IDE support telling you what is selecting what. Events are not colocated on the things they attach to, they could be anywhere.

I can update a React component and be sure that the only places it affects are the places its rendered. And I can get type checking on every input going into a component. That's just way better to me.

I still use JQuery at work, but I usually dread it. And people say JQuery is "smaller" but I would still prefer something like Svelte to Jquery if that's a concern.

I can take or leave Vue, I don't really notice a huge difference between it and other component frameworks.

[treflop]

I’m a big fan of React and jQuery but it sounds like you’re not using jQuery right.

All my jQuery components were self contained and you just initialized them with $(‘[data-date-picker]’).datePicker(). It is pretty obvious to anyone looking at the code that if you remove “data-date-picker”, it stopped being a date picker.

[erhaetherth]

Then you have dumb stuff like if you check a box and want some additional form fields, you have to inject a div or input into the DOM manually, and then make sure you initialize your datepicker, but maybe there will be a flash of unpickerified input if you don't do it right.

[spiderice]

I haven’t used jquery in 10 years or so, but I’m pretty sure this isn’t what you would do. You would just hide or unhide the inputs with jquery.

[Capricorn2481]

That is true, but this is built-in to React and it's optional for JQuery. I am working on legacy projects a lot and nobody ever writes JQuery like this outside of famous libraries.

[rolisz]

React was developed by Facebook. I don't think they did it for small components on otherwise static sites.

[Capricorn2481]

Facebook was a fairly static site back then, but small is a relative term here. I don't mean to say it was only meant to do that. Just that the origins of React are a far cry from the complexity of SPA frameworks like Next JS. And it can still be used as quite a simple drop in component system. Nothing is stopping you from doing that. Which is why people often say React is not a framework but a library, because it's true.

https://legacy.reactjs.org/blog/2013/06/05/why-react.html

[Zardoz84]

what I usually did, was using data-xxx attributes (and document these attributes and how works) to inject special functionality to html elements. I did this with jQuery, and now I do with vainilla JavaScript.

[christophilus]

That's one of the reasons I like them, yes. I've done a lot of manual DOM manipulation, and a lot of jQuery. When you're building anything complex, it starts to become quite difficult to figure out why a particular piece of the DOM is behaving the way it is. It could be an overly aggressive selector that accidentally targeted it, or any number of things.

Prior to React (and similar libraries), DOM manipulation was generally done in a mutating, effectful way. With React (and similar), if a thing is behaving strangely, I just need to go to the component that rendered said thing, and I can almost always find the problem.

[kccqzy]

Yes React is easy to reason about. In fact old versions of React were even easier to reason about than modern versions using hooks (`useState`). I used to use React and just React: no random npm packages, no Babel or any transpilation, no JSX, and it was pure joy compared to jQuery in a complex multi-step form. The jQuery code was in fact spaghetti.

[jmondi]

For your blog, jquery is totally fine and reasonable. Jquery for a web application? That is going to be way more of a headache. It all depends on what you’re trying to accomplish.

[marcosdumay]

I guess the "easy to reason about" thing people keep saying is meant to tell you that the modern frameworks allow modularization.

Personally, I do find their style of modularization abhorrent. As you said, it's full of boilerplate, it's also full of dependencies, and the worst sin in a software architecture: they don't enable you to specify a simple interface between modules. But they do solve the lack of structure you get when all the code talks to each other freely through the DOM.

[docmars]

Creating a brand new Vue app using Vite as your build system (official) takes less than 2 minutes and you can immediately start using Vue by following its documentation and creating a well-organized web application with its friendly patterns and solutions to the most common pro-UX problems you could encounter in a web app.

Give it a shot, it's stupid-easy, and that's not downplaying anything either.

[rjbwork]

This is pretty funny because the front end team at my company decided last year to migrate from Vue to React because Vue is too complicated and it's hard to find people who know it vs React. Impossible for me to get a read on this stuff. Such a clusterfuck of an ecosystem.

[docmars]

Yea there's certainly a lot of mixed opinions and learning curves involved to be sure. On the one hand, I love how many options there are to build web applications, but on the other, it really does feel fragmented and hiring front-end engineers is a huge gamble with all the different preferences involved because there is no true concept of "standards" everyone follows.

Thankfully it's pretty easy to align a team with a little time and learning what everyone wants.

[scotty79]

You can make spaghetti with everything. But without framework spaghetti is even worse. People who make a mess out react do it because they try to use it as if it is jquery.

[genocidicbunny]

> It's very hard to reason about DOM that can be manually changed by any random piece of code.

I think the parents point is that many websites don't need to change all that much DOM manually, automatically, or in any fashion. And I would agree with them, that for when the only 'dynamic' part of your site is one or two simple forms, and maybe a little carousel of images, jQuery may be perfectly awesome.

[williamcotton]

That is not why React became popular. We have to go back to the end of the server-side ORM era. ERB templates creating an LI element in a certain manner and jQuery creating the same element. So have fun keeping those DOM elements in sync! This and the ever expanding DOM APIs led to single page applications where all of the markup was generated by the client. Cue, oh fuck this is slow and oh fuck, page loads and SEO suffers, so then we see the emergence of virtual DOMs along with server-side Javascript, and we are now generating the same DOM elements with the same code on the front and back. Then everyone realized we are making these complex applications with an untyped language with lots of warts… Flow and Typescript emerge.

Guess what? Spooky action at a distance continues with reducers, custom hooks, custom injected contexts, etc, etc.

[labster]

Different use cases. A lot of the web only has only one or two interactive elements in a scope. The DOM being changed by any random piece of code is not a problem when all of the JavaScript fits on two screens. In fact, it’s a benefit here.

[drschwabe]

It's good for quick things and prototyping cause you can always swap out those calls with native later. It's API is generally easier to remember/less typing that most native equivalents. You can also use its API serverside via Cheerio to do parsing & manipulation of html without a dom.

edit: also its way more lightweight than React/Vue/Svelte i don't necessarily disagree you shouldn't reach for jQuery if you have a dynamic page (something like uhtml+preact signals would be good if you have fair bit of rendering logic going on) but I would say you should totally try seeing how far you can get with jQuery instead of Svelte/React/Vue on simple pages.

[zztop44]

Is it really way more lightweight than Svelte? Svelte has more tooling (of course) but it ships no runtime and only sends the user the JS they actually need to interact with your page.

[drschwabe]

Well, if you're talking SvelteKit then it requires a build step so yes, jQuery is way more lightweight.

jQuery is also pure JS whereas Svelte is Typescript so it may be more difficult to debug/hack if your primarily JS coder.

[hsbauauvhabzb]

I learnt jQuery and I would say ‘I could code in jquery, but not pure JavaScript’ - that’s since changed but I do still find foreach jQuery iteration by classname fairly elegant, in addition to $.get and $.post.

I’m not saying that it’s good or bad, but maintenance may mean developers who don’t know or care for modern web don’t have to learn something new.

[Klonoar]

No, if you actually make modules with jQuery where it’s creating it’s own DOM tree, it’s no different from what React & Co are doing.

Reasoning about the DOM structure has almost never been an issue in my almost 20 years of professionally doing this junk. The complexity has always been elsewhere.

[alternatex]

And you're arguing the complexity that has to be somewhere should go in your custom built jQuery modules instead of components built with a well-known framework?

I spent years maintaining front-end code built by devs who believe their way of doing things was better than what's popular in the industry and I disagree about jQuery entirely.

jQuery is a low level tool and always ends up biting people as the project grows.

[Klonoar]

> And you're arguing the complexity that has to be somewhere should go in your custom built jQuery modules instead of components built with a well-known framework?

jQuery + the DOM are well known frameworks. ;P