Element.querySelector[all] performs searches starting from the first child of an element.
Element.closest returns the nearest ancestor.
But this is missing one critical direction – nearest sibling. JQuery supports this with .next().
Maybe another parameter could be added to Element.closest, indicating which direction to search in?
Could you describe a scenario where jQuery’s next method is useful?
Well, I find the need for it (or the non-JQuery equivalent) personally
But a google search of stack overflow reveals it is certainly not a totally neglected feature of JQuery.
The title seems to suggest just querying sibling elements. That can be done pretty easily using previousElementSibling and nextElementSibling properties like your article mentions.
Buuuut I think you want to query next and previous non-sibling elements in the DOM too? Definitely doesnt seem to be anything for that in the spec. But I agree with @simevidas. What is a use case these days where you would need that? Gauging usefulness can be hairy in Google search because adoption may be popular but still a really old way of doing things or may be popular for a special use case. Looking forward to hearing from you!
Hi @mkay581, I’ve added “matching a selector” to the title to be more clear how this differs from [previous/next]ElementSibling.
I can only give general use cases – sometimes you want to find siblings that match a selector, not just children or parents.
In articles arguing why you don’t need JQuery anymore, this functionality looks quite a bit uglier in the native format, making sticking to JQuery all the more tempting.
According to this web site, the usage of JQuery has yet to drop. Why give web sites an excuse? 
Yup, and native specs will continue to “look uglier” than libraries and wrappers. The native web needs to be precise and have the least chance of colliding with other things.
The native web could get a next-style method where you can provide a query to filter with, sure. But it would not be named next almost certainly. It’s too ambiguous as to what exactly you’re trying to get.
I think the bigger driving point here is, Why do we need this in the native web? Doing it by hand isn’t terribly difficult, lots of libraries exists that provide it. Or you could make a simple function in the project to do the task. It isn’t saving all too many lines of code really, so what is the benefit that having it baked in provides?
Well, I guess you would be in favor of throwing away maybe half of all the api then that’s already built into the browser? Or at least think it was a mistake? Should the browser never have attempted to incorporate JQuery’s popular features into the browser?
I agree with you that use of the name next(), as JQuery uses, would be confusing.
It’s kind of interesting that the browser incorporated JQuery’s “closest” method (at least a subset of it), even sticking to the name. It’s not clear to me that implementing “closest” saved that many lines of code either, when looked at from the point of view of a single application. Was that a mistake? It seems like there’s some mathematical formula that would ideal to be able determine what is worth adding to the browser: (lines of code needed to implemented) * (number of web sites that use this functionality). The big problem is there doesn’t seem to be a scientific way of determining the second factor.
I think it’s kind of confusing to have “closest” that only matches going up, and querySelector that only matches going down, and nothing that matches going sideways. Has anyone scientifically determined that searching sideways is significantly less needed than the other two directions? My guess ( in terms of volume of use) would be down => sideways => up, so having jquery’s “closest” but not “next” is a travesty of justice
My vote would be to simplify the learning curve, and enhance “closest” with a second parameter, to be able to specify what direction to search in, which would effectively cause querySelector to be redundant (I think). Directions could be ancestor, descendant, previousSibling, nextSibling (and maybe some combinations?). For backwards compatibility, ancestor would have to be the default. “Closest” is a lot easier to understand than “QuerySelector.” Plus it’s shorter (especially if that second parameter could be made small, like ‘^’, ‘>’, ‘<’, ‘v’).
I also wonder whether when browsers implement these features natively, they might have any fancy techniques for caching results?
There are other precedents for duplicate functionality being provided in the browser api as the browser evolves…
Just my two cents
There is a fine line between adding a few of the higher-end helpers and adding everything in. It’s a very slippery slope. I’m fairly certain all of jQuery was reviewed at some point and decisions made on what to move in and what not to. At this point, it would need to be a very compelling reason to pull something else in from it.
We can’t just stuff everything in because it exists and someone finds it useful. Everyone will find everything useful. Justification behind use-cases matters, especially to show there is a benefit to including it in the engines vs letting it exist in user-land.
Also engines have different naming conventions to be more explicit and allow for future expansion cleanly. querySelector is named for this kind of purpose. We shouldn’t go stuffing more names in to the same methods just to appeal to some “learning curve.” Developers deal with multiple varying APIs all day in their work, this is no different. We have powerful tooling and documentation resources to aid us in discovering and using these various APIs. It’s OK. We don’t need every little thing to relate to every other thing in any other given system or language.