jQuery 3+ minified is 31Kb.... Wtf is the problem with that? Can we just admit that vanilla JS is not ideal and having some abstraction (and tiny bit of page load) is worth it? I am not building web apps that are primary used in Sudan with 1G connection. 31Kb is practically nothing. THIS image is larger than that! http://content.cdn.viber.com/stickers/144/10400/00010400.png
You might not need jQuery (2014)
81–90 of 241 posts
Re: You might not need jQuery (2014)
#82Earlier quoted context omitted.
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?"
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.
Re: You might not need jQuery (2014)
#83It's ironic that there's probably no bigger sales pitch for jQuery than this site. In every single example, the jQuery version is basically one or two lines of code, versus 10-15 lines for the alternative. (and the jQ version seems significantly easier on the eyes as well.) Also, jQuery supports promises and has for quite a while. This page hasn't aged well. I've come full circle and am now using jQuery again.
I doubt the “choose not to use jQuery” path means “never write a function to wrap up that boilerplate”. The point is that you might be able to write the equivalent function instead of pulling down a whole library. That said, optimization techniques have gotten good enough that you might be able to just let a build tool do that for you. If you really still want to use jQuery.
jQuery is immune to modern optimisation techniques such as three shaking (only including the modules actually used) because it’s fluent interface makes it a gorilla that holds quite a few bananas, even if you only need one of the bananas.
Re: You might not need jQuery (2014)
#84jQuery 3+ minified is 31Kb.... Wtf is the problem with that? Can we just admit that vanilla JS is not ideal and having some abstraction (and tiny bit of page load) is worth it? I am not building web apps that are primary used in Sudan with 1G connection. 31Kb is practically nothing. THIS image is larger than that! http://content.cdn.viber.com/stickers/144/10400/00010400.png
JQuery is orders of magnitude slower than vanilla JS. It’s not about download time but execution time. I am not deliberately trying to punish my users.
Re: You might not need jQuery (2014)
#85Earlier quoted context omitted.
I would prefer web developers accepted they need to write a few hundred lines of 'ugly' vanilla JS to drive their website than they include a 30KB library that they only really use 0.2KB of. On the web, user experience should really be a higher priority than developer experience.
Hundreds of lines of ugly vanilla JS which duplicate jQuery features which aren't as well tested and probably don't handle all the edge cases. > On the web, user experience should really be a higher priority than developer experience. Those aren't disconnected. The more time I spend on technical implementation details, the less time I have to think about UX and/or implement things that improve UX.
You just have to chose the right tool for the job and the limitations. You get something in return for doing the extra work and you get something in return for glue coding some libs. Also keep an eye on the experience points.
Re: You might not need jQuery (2014)
#86What we need in 2021 is not this site, it's a youmightnotneedreact.com
I would say that this corollary would only be possible once webcomponents have form support in all browsers. In my opinion this is the last major hurdle before there is a native alternative for reusable components in the browser. Firefox is working on it[1] but there's no current roadmap for the work for Safari (though the initial form element proposal was well received by their team).
Re: You might not need jQuery (2014)
#87What we need in 2021 is not this site, it's a youmightnotneedreact.com
And of course in 2021 you could build the site using Vue with GraphQL and a CDN deployment pipeline with auto scaling :)
Build it as a single document in pure html + inline css with 20 mb of text on it and lazy loading images.
Re: You might not need jQuery (2014)
#88The need for convenience libraries is like parenting with television. It doesn’t seem bad and is just so much easier in every possible way, but any objective observer readily sees the difference in quality of product.
The primary reason for that distinction is that you are willing to spend a tiny bit of effort on micro-improvements to quality of product or aren’t, just like parenting. Yes, the effort is ridiculously tiny because it pays for itself with only a trivial amount of practice.
Re: You might not need jQuery (2014)
#89The need for convenience libraries is like parenting with television. It doesn’t seem bad and is just so much easier in every possible way, but any objective observer readily sees the difference in quality of product. The primary reason for that distinction is that you are willing to spend a tiny bit of effort on micro-improvements to quality of product or aren’t, just like parenting. Yes, the effort is ridiculously…
Not sure whether the comparison is apt. Especially during the lock down, parenting without using Media ... well, it does not involve a „trivial“ amount of practice or a „ridiculously tiny“ amount of effort.
Re: You might not need jQuery (2014)
#90Now only if someone could combine the snippets on the right hand side in an easy-to-use library. Oh wait...
no no no... what we need to do is break them down so that each line is a separate library composed of a single function with its own independent dependency tree and test suite, then build another library out of that, all written in a language that compiles to javascript, and publish it to a proprietary package manager. If we're really clever we can probably get it up to several megabytes, require three languages and…
I like the functions (that were suppose to do things) calling functions suffering from the same issue.
We're not in kansas anymore.