[jart]

This comment is a great example of what I call "lines of code mindset" which is form of tip of the iceberg mentality, where programmers optimize for simplicity only the code they see. Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? Hidden complexity you don't control is the most expensive kind I think.

[arp242]

It's 77k for the latest version, and after compression it's ~32k. It's really not all that large. You can also reduce this to about ~27k if you exclude some less-commonly used things like animations, shortcuts, etc.

JS people be like: "86K jQuery dependency is wasteful!"

Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"

[tomtomtom777]

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.

[ryanbrunner]

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.

[WorldMaker]

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.

[Viliam1234]

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...

[mad182]

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.

[hajile]

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.

[hu3]

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

[hajile]

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.

[hu3]

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.

[toper-centage]

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.

[varrock]

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.

[arp242]

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.

[necovek]

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).

[braveyellowtoad]

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.

[arp242]

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 :-)

[robertlagrant]

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

[lmm]

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

Yes, absolutely. That's a total no-brainer.

> Hidden complexity you don't control is the most expensive kind I think.

There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your custom implementation of whatever it was than in jQuery.

[capableweb]

> > Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

> Yes, absolutely. That's a total no-brainer.

That's what we've been thought but it's not a no brainer at all. Context matters, but you disregard it and only focus on the lines of code, just as the author of the comment you respond to is saying people do.

You're building a marketing page that's not gonna be updated after completed and only gonna be valid for X days? Sure, the code doesn't matter.

You're trying to build a fast and slim UI that's gonna be deployed on routers and possibly loaded on low-power devices? You better care about every single line that gets loaded on the device.

I'm not saying dependencies are always wrong. I'm also not saying it's always right. I'm saying why you need the dependency and the quality of the code it includes is important to consider, and knee-jerk reactions of "of course I'd use it" is hurting the profession more than the library reuse saves us currently.

[lmm]

> You're trying to build a fast and slim UI that's gonna be deployed on routers and possibly loaded on low-power devices? You better care about every single line that gets loaded on the device.

Unless you've gone out of your way to buy a (more expensive) part with less memory, your router will have enough memory to make 86.1Kb an utter irrelevancy; so will most of what were traditionally considered "low-power devices". Yes there are extreme cases where it matters, but we're talking about a vanishingly rare proportion of use cases.

> I'm not saying dependencies are always wrong. I'm also not saying it's always right. I'm saying why you need the dependency and the quality of the code it includes is important to consider, and knee-jerk reactions of "of course I'd use it" is hurting the profession more than the library reuse saves us currently.

I think this is backwards, and the knee-jerk reaction of "of course it's important and you need to carefully think about it" is what's holding back the industry. The overwhelming majority of the time, the right thing is to use the dependency; the best development practice is to default to using dependencies and reassess if and when it you hit an actual problem.

[petecooper]

>> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency? >Yes, absolutely. That's a total no-brainer.

I'm curious - would you be able to elaborate, please? Thank you.

[porker]

Assuming I'm going to need the complexity more than 1-2 times in my source code, I'm going to be writing my own abstraction. Which takes time, needs tests writing, and I am going to make a typo or other silly mistake somewhere.

Run into a couple of examples of such complexity, and the dependency is well worthwhile.

A jQuery that can be tree-shaken would be awesome, as there are parts I use regularly and others I have never used. Ironically the -lite bundle leaves outs parts I use frequently...

[lmm]

Just look at the cost-benefit. Typically internal code has a defect rate of around 1/1000 lines, so 10-15 lines is about 0.01 bugs. 86.1Kb of an established, widely used library is a cost that I can't meaningfully distinguish from zero.

[jamiesonbecker]

> Hidden complexity you don't control is the most expensive kind I think.

That's called encapsulation. :)

Seriously, encapsulating complexity is the foundation of most programming paradigms.

[userbinator]

In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better.

Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.

[nicoburns]

> In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to, so the less of that there is, the better.

jQuery's not a very good example of this though. It's one of the most widely used, and hence most tested and least buggy pieces of software out there. Nowadays the web APIs are pretty solid, but back in the IE6/7/8 days the jQuery API was a lot less buggy than using the built in APIs directly.

[scubbo]

Have fun implementing everything from scratch in assembly.

[jamiesonbecker]

> In the real world... From experience...

Does jQuery (est. 2006) have more bugs in it than your code?

[quattrofan]

As has been seen many times recently third party libraries are a major attack vector for the bad guys.

[donapieppo]

> In the real world, it turns out that code you didn't write can also have bugs or not behave as you expect it to

To me this seems a comment that only stands for one-developer projects.

[franklyt]

Actually, it's called abstraction, as a technical point.

[jamiesonbecker]

Good point. This is what I was referring to:

https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...

[notjustanymike]

It's never just 10-15 lines, and I'll always take 86Kb of a properly tested, production environment validated, properly documented, community supported, cross-browser library over the one-off functions I frequently squash in code reviews.

[bryanrasmussen]

>is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

I don't actually use jQuery any more but obviously if you are using it, you are saving the 10-15 lines every time you use one of these methods, not 10-15 lines in your whole application. I have a hard time believing that the savings of code lines will not be close to the weight of the dependency in any medium sized company codebase.

[viseztrance]

Lines of code is a bad metric for complexity.

Jquery is a thin wrapper over javascript, whereas React has a comparable size but is a significantly higher level abstraction.

[nickjj]

> Is saving 10-15 lines worth it if you need an 86.1 Kb vendor dependency?

There's projects like https://umbrellajs.com/ which are very similar to jquery's APIs for DOM manipulation and it's only 2.5kb gzipped.

IMO it's a nice balance between having a convenient API without bringing in the world.

If I could write 2-5x less code and it's easy to remember I would make that trade off every time.

[spiralx]

A vendor dependency that's almost certainly locally cached already if you use one of the common CDNs for serving jQuery - ajax.googleapis.com, cod.jquery.com, cdnjs.cloudflare.com or cdn.jsdelivr.net.

[M2Ys4U]

Browsers are now separating out caches per origin so that benefit has gone away.