Hacker News Reader

Comment by knoebber | Hacker News Reader

I think the main use case today is the dom traversal API. It makes operations like "add the 'error' class to all <input> elements in the form" simple:

    $('#some-form').find('input').addClass('error')

Obviously you can do this in vanilla JS, but it's more cumbersome so you'll probably end up rewriting your own less complete version of jquery. There is some value to using a well worn library with public documentation that other developers can find/extend instead of a home grown solution.

With that said, I wouldn't use it for a green field project. For sites that require lots of interactivity I would pick a modern front end framework that doesn't require this kind of manual dom traversal (probably phoenix/liveview).

View on HN

Mostly off the top of my head:

    document.getElementById('some-form').getElementsByTagName('input').forEach(i => i.classList.add('error'))

It is a little more verbose but it isn't that much more cumbersome today.

That's also doing things "the right way" and not do-all selectors, but that option exists now, too:

    document.querySelectorAll('#some-form > input').forEach(i => i.classList.add('error'))

If you want to make it a little less verbose:

   const $ = document.querySelectorAll
   const addClass = (className) => (item) => item.classList.add(className)
   $('#some-form > input').forEach(addClass('error'))

However getElementById() can return null, thus that entire statement can error. In the old days you had to sprinkle your code with if checks when using the DOM API.

If you are requiring that element to be there for your script to work then that error is exactly what you want. Defensive programming is great and all, but sometimes your assumptions have to meet the road anyway and script errors are a perfect way to signal something went wrong (because that's what they are for).

Of course now we have additional defensive programming tools like `?.` and `??` operators.

It depends, if the page is very dynamic the element may or may not be there.

Point is that the DOM API version of the initial jQuery snippet are not equivalent. $() statement does a bit more than that.

This becomes obvious if the requirement are a bit more complex than the example, perhaps we want to chain more expression on at the end, then the DOM API version becomes more convoluted.

Love the syntax in the last example, you should make it into a library!

Maybe that npm package could get as famous as leftpad.

Is it that hard to:

    document.querySelectorAll("#some-form input").forEach(e => e.classList.add("error"));

No it's not

This won't throw an error if the form ID changes. Which is to be expected for working on collections. But I don't like this being the default, exactly because of cases like this.

Same thing of course applies to people who throw around the optional chaining operator without thinking to please TS.

Or would apply if one used a single selector here and document.querySelectorAll

The needless chaining here is a typical example of misleading jQuery code though. Looks as if it was there to prevent this issue.

What's wrong with

  for (const input of document.querySelectorAll('#some-form input') {
    input.classList.add('error');
  }

In fact, this has an even earlier baseline browser compatibility than

  NodeList.prototype.forEach

I can't really imagine willingly doing something nontrivial without a reactive framework these days. I'd be all for jQuery if I did want to do that though.

I almost always fall back to jq if it's loaded, vanilla js APIs are so annoying.

Reply on news.ycombinator.com