Live data from Hacker News

I loved jQuery, and still do (2019)

withblue.ink

81–90 of 189 posts

Re: I loved jQuery, and still do (2019)

#81
post #49

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.

[deleted]

Re: I loved jQuery, and still do (2019)

#82
post #74

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

It's not going to take 15 minutes to understand WebPack and Parcel. Let's be a little more realistic. Sometimes you don't have the luxury of time and tools that you already know are going to get used, instead of new tools you don't.

Re: I loved jQuery, and still do (2019)

#83

I 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…

note that jquery is already cached in browsers and infinitely more performant than some random low IQ web developers js bundle of the day

Re: I loved jQuery, and still do (2019)

#84
post #74

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

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)

#85
post #61

Every 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…

That site is generally aiming at providing exact replacements, and quite a few of its examples are not great for various reasons:

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)

#86
post #74

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

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 didn't know you had while being happy you can't compile your frontend project on a small raspberry pi. It's not because you can use all those tools than you should

Re: I loved jQuery, and still do (2019)

#87
post #6

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

The jQuery API is really good. It's still better than the DOM API, it's just that now, your framework might give you some of what it does, and the DOM API is almost good enough (and free). You're right about how it was historically misused, thought that has less to do with jQuery than a lack of good client-side frameworks, design patterns, and how rich frontend experiences used to start as just a few callbacks.

Re: I loved jQuery, and still do (2019)

#88
post #74

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

Parcel is literally zero configuration, maybe that would have been a better solution for your usecase. You need to understand some Webpack basics for it to be functionally useful, but all the criticisms of Webpack could easily be levied against jQuery and some.

Re: I loved jQuery, and still do (2019)

#90
post #74

Earlier 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 are literally criticising Webpack for its best features. Identifying outdated libraries and potentially dangerous vulnerabilities is a huge plus for Webpack. Do you think just because you include a CDN lib in the global space vulnerabilities just magically go away?

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.

Post reply on HN