There is an additional cost to such a dependency that isn't expressed in bytes.

Javascript/CSS/HTML forms the common basis of web development. You may assume every reader of your code is familiar with it.

If you use a specific library, you are restricting (easy) readability to those that know the specific library.

This has merit if the library provides sufficiently useful abstractions or shortcuts, but it's only a drawback if the library provides merely an alternative way to write something already possible in the base layer.

That's fair, but I also think that JQuery is often judged much more harshly than other libraries that have a significantly higher learning curve.

I know plenty of developers who would view inclusion of JQuery as some cardinal sin due to reasons like the ones you state, but don't apply the same logic to React, Redux, or other more modern, significantly more complex libraries.

I think a lot of that is the "problems they are solving" and "problems they left behind for the developer". JQuery was built to solve "browser compatibility issues" and left behind things like "component structures of code/code organization", "data-flow organization", and more as out of scope.

Browsers have since mostly fixed "browser compatibility issues" at the standards level, so that problem technically no longer needs solving.

As applications have grown larger those other things that were out of scope for JQuery have become bigger and bigger problems that developers face. (Of the big two I mentioned React solves one, Redux solves the other.)

Some people see JQuery as a "cardinal sin" for the first issue: browsers have already "solved" this, this is a deadweight because it fixes a problem I no longer have. They would have fewer problems with React/Redux/whatever because they solve new problems.

Some people see JQuery as a "cardinal sin" as much for the latter issue: because JQuery was so unopinionated on code structure, data flow, component structure, it led to a lot of real world code that was "JQuery spaghetti" littered with anti-practices like relying heavily on global or might as well be global variables for state information, with no structure to which code might impact which variables and when. Componentizing a JQuery system was often a lot of hard work that JQuery itself didn't help with (and given it's own common usage as a window.$ global with sometimes surprising bits of hidden state inside it, in some cases directly hurt those efforts). Given libraries like React or Redux were designed to solve some of the problems that JQuery once created, it also seems clear why some developers might be very vocally antagonistic to JQuery but have no problem bloating a project with tools that solved those problems and/or have more structure and opinions on building "good" componentized/compartmentalized structures.

Not a front-end developer, but could this simply be a generational issue? Every framework invented before my career is a clumsy dinosaur, every framework invented during my career is the silver bullet that will solve all problems...

The size argument against jquery has always dumbfounded me. Bundle sizes in megabytes, "node-modules" folders with thousands of files and hundreds of megabytes are fine for modern web apps, but if you dare to mention jquery, you can bet someone will cry about overhead and waste.

Sites looking to use jQuery most likely aren't doing much more than a few event handlers and an interactive component here or there.

In those cases, I'd argue pReact is superior. It's almost 10x smaller (29kb vs 3.5kb gzipped). It's faster and more structured leading to less maintenance cost and more code reuse. If you use hyperscript, there's also no JSX compilation required.

I'd like to learn about usage of preact with hyperlink or similar. Do you know of a repo I can take a look?

I think that's hard to ascertain because it's a drop-in replacement for react. I assume you mean hyperapp instead of hyperlink.

It gets around a half-million downloads per week according to NPM stats while hyperapp gets under 3k per week.

Yes. Or hyperscript as my parent posted. I'd love to see an example of preact with it.

But looking at the repo https://github.com/hyperhype/hyperscript I have a hard time imagining how preact can work together. They seem to overlap in functionality.

You can either use their native `h` (basically createElement in React)

https://preactjs.com/guide/v10/tutorial/

or you can use the full hyperscript markup library

https://github.com/queckezz/preact-hyperscript

That's a very good point. We have been hating JQuery for so long, that we didn't notice that it's size when down while app size inflation grew exponentially. 15 years ago loading 50kb of bloat was reason to worry, today no one bats an eye.

I just want to mention that you are replying to someone who never said anything about SPA. They made an interesting point about trade offs.

It describes the general attitude of the community; go to /r/javascript or /r/webdev and mention jQuery (...if you're brave enough) and you'll get those kind of responses, often accompanied that you should be using "modern tools". Then mention multi-megabyte JS bloat and you'll get those kind of responses as well, in the very same thread, and the very same people will be argueing both points at the same time.

While your points might be true, you are arguing how there are hypocritical and dishonest people somewhere else.

You are also putting a heavy burden of proof on your readers: it generally sounds implausible that exactly the same people would complain about <100kiB being bloat and >1MiB not for the same use-case, but I am not going to go and fact-check that (with the implausibility of the claim, I would expect you to give direct pointers yourself or will simply distrust your claim).

You seem to know quite a bit about this, do you know why there isn't some sort of a "compile" phase where the jquery examples wouldn't be translated into the minimum js equivalent? Seems like then you could get the same syntax and minimum size.

You mean translating jQuery to "native JS"? I suppose it's possible, but I don't know if anyone built anything for it.

All I know is that you can build a custom jQuery build with grunt, as described in their README, which is what I do. I mostly use JavaScript as if the last ten years didn't happen, so I'm hardly an expert on any of this :-)

Good point: different JS people have different opinions on tradeoffs.