Some people talk big about dropping jQuery and saving one request, yet they have a shipload of bloat elsewhere. Not using jQuery in and of itself is not an optimization of any kind. I use jQuery and my page has a perfect score in GTmetrix. If the goal is optimization, you have to consider the total package. Addititionally, jQuery loads on the first request and sits in local cache thereafter. And it could already be i…
It won’t be cached already. Safari, Chrome and Firefox all have partitioned cache now.
I loved jQuery, and still do (2019)
81–90 of 189 posts
Re: I loved jQuery, and still do (2019)
#82Earlier quoted context omitted.
> If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.
I respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
Re: I loved jQuery, and still do (2019)
#83I love jQuery. I can just drop in the library onto any existing webpage, and have almost complete control of the DOM with just a few lines of code. And the built in actions and animations are all so simple and perfect for the web. And the structure and naming is so good that I rarely need to look up any references anymore. I get that browser support isn't as important as it used to be, but it is nice to know that you…
Re: I loved jQuery, and still do (2019)
#84Earlier quoted context omitted.
> If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.
I respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
Re: I loved jQuery, and still do (2019)
#85Every time anything about jQuery is posted, someone will inevitably post the "You might not need jQuery" site. [0] I look at that site and laugh. Is this supposed to be making the case ~against~ jQuery? Maybe the audience for that site are seasoned developers for whom the vanilla JS syntax is easily understood. Everybody else is going to look at those code snippets and think jQ is the way to go. For people that have…
Some use a bad technique; e.g. “Empty” removes the first child repeatedly, which is O(n²) in many environments, rather than removing the last child repeatedly, which is O(n), or `el.innerHTML = ""` which is shorter and more efficient in general)
Some suffer because they’re supporting IE which no one should do any more (fite me); e.g. “JSON” is long because it’s using XMLHttpRequest, but the Fetch API would make it vastly shorter (`data = await (await fetch('/my/url')).json()`—as an aside, suffix await like Rust settled on is so much nicer: `data = fetch('/my/url').await.json().await`); and “Each” should use `document.querySelectorAll(selector).forEach((el, i) => …)`; and “Matches Selector” is just `el.matches('.my-class')` now.
Also some look bad because jQuery optimised an operation that isn’t terribly common or should generally not be done, such as most of the width/height things (most uses of measuring element dimensions in JS are unnecessary, bad or wrong; aim to use CSS most of the time), “Index” (needing to know that an element is the nth child element is decidedly esoteric), “Type” (if you use this, you’re almost certainly doing the wrong thing), and “Parse HTML” (picture me running away, screaming in horror; this method is practically a primed security grenade). And remember, jQuery having optimised these things means you’re paying to ship that stuff that you’re not using.
And finally some seem more complex because they’re matching some unnecessary jQuery complexity, e.g. in “Set Height” (and alike in “Set Width”), $(el).height(…) takes a string, a number, or a function that returns a string or a number—but you’d be wiser to write `el.style.height = string;` or `el.style.height = number + 'px';` rather than being unnecessarily flexible.
Most people that use jQuery use a tiny subset of its functionality. The site is about showing that most uses of jQuery could actually dispense with it at little cost, if they’re the sort that value performance and such and want to ship less unnecessary code.
Re: I loved jQuery, and still do (2019)
#86Earlier quoted context omitted.
> If you like quick and dirty, just make sure you have a working Node.js environment and generate a simple project that supports Webpack or Parcel There’s nothing quick or easy about these steps. Linking to a jQuery CDN and getting working code immediately is easy.
I respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
Re: I loved jQuery, and still do (2019)
#87I'm not the biggest fan of jQuery because I have had to deal with massive tech debt created by other engineers over the years (and I'm not a frontend dev). However the Ajax API is a genuinely good tool.
Re: I loved jQuery, and still do (2019)
#88Earlier quoted context omitted.
I respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
I've been dealing with Webpacker for almost a year and it's been a nightmare every time I've tried to use it. And yes, I did sit down and try to figure out what the hell was going on.
Re: I loved jQuery, and still do (2019)
#89Re: I loved jQuery, and still do (2019)
#90Earlier quoted context omitted.
I respectfully disagree. If you take 15 min to understand the basics it becomes trivially easy and the productivity you gain going forward is massive.
I respectfully disagree if you have some other things to do in your free time than maintaining dependencies, trying to figure out why your project won't compile at all in 6 months of time while reporting 100 security issues, what will be the next change in webpack to will require to update both your config and some plugins, why does npm now cry for you to use a "--legacy-peer-deps" flags to nicely handle dependencies…
You also don't need to include packages that are poorly engineered and maintained. For what you do decide to use, you are getting visibility into the warts that you may have blissfully ignored in the past.
The issues you are describing are not really problems anymore unless you let your app get woefully out of date. The web and browsers are a moving target, so it's critical that you minimize running legacy code wherever possible. Npm/Yarn and Webpack is a huge step in making that manageable. jQuery has been on autopilot for years because it has limited usefulness. We've collectively moved on except for a few holdouts.