Hacker News Reader

Comment by wkirby | Hacker News Reader

I'm consistently surprised by the commenters on HN who seem to think jQuery is just a DOM selection library, when in fact it is a widely supported, incredibly stable tool set for (yes) DOM selection, but also attribute manipulation, Ajax requests, event handling, animation, and general utility functions. What's more, where there _is_ native functionality that replaces jQuery, the API is never as fluent.

For work that needs a little enhancement on top of server-side HTML, but not a full-blown JS UI framework, jQuery is a small price to pay for a stable, reliable, and cross-browser compatible dependency.

View on HN

A few years ago I dropped jQuery for plain vanilla js and I've never looked back. Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins", that usually only do what they want to do and not much else.

Yes, the vanilla selectors are more verbose, but any half decent code editor will make them just as fast to type. I don't mean to be penantic, but I don't really understand why so many people still use jQuery at all.

https://youmightnotneedjquery.com/

Look at your own link - the "modern" way of doing it is always about 2-3x as verbose as jQuery. Editors let you type that mess faster, but you'll still have to read through it, maintain it, scroll it into view in your editor, see less of it onscreen at a time, etc. I'll take a clean, succinct API over a noisy verbose cumbersome one any day.

And what are we saving by eschewing it and going vanilla? One little 30kb-gzipped javascript file - smaller than most jpegs. I agree for super simple tasks it might be best to skip it.

The DOM API is a sloppy and hastily-designed pile of crap from the OOP era that we're unfortunately stuck with for legacy reasons. jQuery shows what it could have been.

You just described why I use slim-lang in all of my projects. produces clean, correct HTML with zero noise.

Ends up eliminating 50-60% of the code, and the time for writing and reading it.

As for jquery I haven’t needed it much since stimulusjs but loved it whenever I used it.

I'd only drop jQuery/lodash if you were adding Typescript. And I do prefer dropping them for Typescript, but the previous are still cool.

That is not correct at all. The DOM API is entirely functional based upon traversal of a lexically scoped model. It may not be as declarative as you like but lying about what it is because it makes you feel uncomfortable is rather ignorant.

> The DOM API is entirely functional based upon traversal of a lexically scoped mode

wat

DOM APIs have been, and still are, 90s-era OOP style with zero attempt at being functional, declarative, or composable.

Even the newly developed API are usually stuck in the same mindset (see everything developed for web components)

The DOM is a big in memory object but the DOM APIs are entirely functional. Functional is not the same as declarative.

> DOM APIs are entirely functional.

(Almost) none of the DOM APIs are functional. They are literally `object.methodCall()`

Yes, functional programming can have methods. Methods are functions. OOP is all about polyinstantiation and inheritance. Functional programming is all about functions and input/output, which is entirely what happens in this case. The only OOP here is the method assignment you don’t see: Element.prototype.getElementById = function () {};

You're making no sense. Functional programming is more than just "about functions".

DOM APIs are the embodiment of 90s-era OOP. There's literally nothing functional about them. All [1] "functions" are methods defined on very specific objects. You can't even get a proper reference to them without binding them to specific object instances

What exactly is functional about this?

  const newDiv = document.createElement("div");
  const newContent = document.createTextNode("Hello, world");
  newDiv.appendChild(newContent);
  const currentDiv = document.getElementById("div1");
  document.body.insertBefore(newDiv, currentDiv);

Okay, here's an easier question. What will happen here, and why?

   const function_reference = document.getElementById;
   function_reference("#id");

[1] Technically speaking, not all all. The more recent `fetch` is probably the only piece of browser APIs that can be called functional for some very limited definition of functional

Most (all?) other "global" functions are defined on the instance of the window object: getComputedStyle, getSelection etc.

> What exactly is functional about this?

A series of function calls that each do something and each returns a value.

> Okay, here's an easier question. What will happen here, and why?

A function call that does something and returns a value, because in this language complex types are passed by reference.

> A series of function calls that each do something and each returns a value.

Doesn't make it functional

> A function call that does something and returns a value,

Ah, so you don't know.

Here's what will actually happen:

      TypeError: Can only call Document.getElementById on instances of Document

Because it's a method on an object. And you have to bind that method to a specific object instance before you can call it.

If it was functional this would never be the case. But since this is 90s-era OOP, you have to do this:

      const function_reference = document.getElementById.bind(document);
      function_reference("#id");

> A series of function calls that each do something and each returns a value.

This is not what functional programming is. Functional programming is a completely different paradigm for writing code, and it _is_ declarative by definition. The Wikipedia definition is pretty decent:

    Functional programming is a programming paradigm where programs are constructed by applying and composing functions. It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values, rather than a sequence of imperative statements which update the running state of the program.

The "Comparison to imperative programming" section[1] offers a decent example of the paradigm, but DOM manipulation in JavaScript is pretty much as imperative as it gets. Having functions is necessary, but not sufficient, for functional programming.

[1]: https://en.wikipedia.org/wiki/Functional_programming#Compari...

Hate to pile on, but this is absolutely not the definition of functional programming.

Functional programming uses stateless, immutable transformations to contorl data flow. The second you instantiate an object with some internal properties that change in memory, you are no longer programming functionally

Some of those examples aren't really equivalent. If you use that vanilla js way to show/hide, it won't restore the display property to the value it was before using hiding. It will just shift it between display: "none" and display: "". If you need something to be a display: "inline-block", the vanilla js example will lose that and break your styling.

You can modify the code to set the display property as inline-block, but now you need a different show function for every possible display value you want to restore. Or you need to build a layer of state to remember what the original value was and hey you've rewritten the jquery version.

And this is all ignoring that the jquery versions just look so much simpler to remember and are cleaner to read.

Except you can do this:

```css .hide { display: none important!; } ```

```js function hide(el) { el.classList.add('hide'); } ```

LMFAO every example of "modern" looks like a course in how not to design an API, etc. The jQuery examples are so clean and expressive. Imagine landing on a page like that and thinking, "hey, that 'modern' option looks good." You'll end up with 28KB (jQuery gzipped size) of just extra syntax before you're done with your app, not to mention the additional 160 hours of work.

You'll likely be adding 6-700KB of React and its ilk anyway (I see it in every project now).

The code I write these days is cleaner and more readable than anything I did back in the jQuery days. The only thing I add (for bigger projects) is Typescript.

With jQuery it feels like a lot of functionality is hidden away, which can lead to unexpected situations that are harder to debug.

In my experience writing vanilla code takes less time, not more, because I have a better grip on what is happening.

> Native js has everything jQuery has, except for the pile of often poorly maintained half baked "plugins"

The great things about these plugins is that you can strip them down to what you need and patch them yourself (remember lib or vendor directory). NPM and build tools make this a chore.

Stripping them down is work, especially with the type of code that can often be found in random jQuery plugins.

It could be argued that avoiding unnecessary work is my main job function. It's a lot more efficient to just get something that already does what I need, without requiring patches. In my experience leaving the jQuery ecosystem made this a lot easier.

"I don't really understand why so many people still use jQuery at all."

Because it has a beautifully designed API. I don't directly use jQuery usually anymore. But I use the API in a basic DOM wrapper I've written. https://gist.github.com/pseudosavant/b86eedd9960ade958d49447...

> https://youmightnotneedjquery.com/

I'm convinced this site is actually satire and it designed to promote jQuery. In nearly every example, the native version is far more verbose.

It's just a random site I remembered from a long time ago, there are better ones out there. One of them convinced me that jQuery is just a crutch. I tried a small project without it and it really did not take long to adjust.

These days I find vanilla far easier to read and it is a lot more clear to me what is actually happening in the code.

Depending on jQuery limits your ability to work with code that does not use it. Ie a lot of the more professional libraries.

For me dropping jQuery feels like a step up. Why don't you just try it, see what happens. It's just a day of being a little bit annoyed and then you should be fine.

FWIW, I'm not a front-end developer. I've had to do some over the years, but it's certainly not my area of expertise (I work in AppSec), so my opinion is worth very little.

jQuery might be a crutch, sure, but I'm not sure crutches are a bad thing. There's no reason to make something harder than it has to be. I just like how some things take far fewer key stroke and are less verbose, but still readable.

Readability is subjective. There are people that think Perl is fine and I think it ranks as one of the least readable languages to ever reach popular status. Meanwhile, I think Python is the most readable language to have ever been created, and somehow some people struggle with it, and tbh it kind of blows my mind.

your link actually convinced me that jQuery is a much better alternative to vanilla js.

I don't think it's that surprising given the demographics of HN posters that I've observed. Many will immediately reach for the big JS framework du jour when they need anything more than a little DOM selection stuff, because that's what they've always done.

There's 2 types of web pages. Websites and web apps. If you're building a web app, you're going to want a framework that isn't going to fall apart the second things start getting complicated. If you're making a little marketing website, sure, sprinkle some jQuery on there and call it a day. Probably better for performance and SEO unless you want to spend 10x as long micro-optimizing your SSR. Point is, there's different use-cases.

It’s all the same. The difference is not in the product but in the developer’s perception of the product. The code and the user don’t notice the difference, just the developer in the middle. There are those who can dynamically put text on screen and those who need just a little help to dynamically put text on screen.

> the user don’t notice the difference

Users do notice the difference is large JS framework driven applications.

Yeah, they notice how slow and janky they are, and how often they're staring at empty gray boxes while things load.

Okay, what part of what I said are you trying to refute or educate me on?

There's a large proportion of posters on HN who spend their days building web apps. They are very likely to stick to using what they know, even when building web sites.

If you spend your days working as a welder, and suddenly need to build a box for some reason, you're probably not going to be breaking out the fine wood joinery tools. You're probably going to take some sheet steel and weld up a box and move on to whatever else you have to do.

It's not a problem, it's not a fault, it just how things are.

> Okay, what part of what I said are you trying to refute or educate me on?

Not the GP, but that's why, when applicable, I try to prefix my replies with a variant of "I agree, and btw..."

> commenters on HN who seem to think jQuery is just a DOM selection library

proceeds to name selection and native functions

> just

yes and far easier to drop jq into a project.

no need for build tools and all headache. (i know you do that with react but its not comparable features).

You don’t run your JS through babel or minification?

why would I?

for a small project those efficiencies wont make a difference on my $20 godaddy hosting account.

i dont want some tool or process getting in my way. if i have a problem then i will look for a solution.

This, so much.

I do like SPA also, but some of the nicest projects I've worked with could be run locally by launching `python3 -m http.server 8008' on the right folder.

I'm happier when I can do something without a processing step, or the need for a package.json. Need a third-party script? Vendor it, and never have to worry about supply-chain attacks.

For browser compatibility?

Reply on news.ycombinator.com