DEV Community

Why I won't use querySelector again.

Ayobami Ogundiran on January 14, 2025

The JavaScript ecosystem is always evolving and it is time for another wave of the future. We all loved it when jQuery was baked into browsers as ...

Read full post

Ben Sinclair • Jan 14

I'm looking at your initial issues and I don't think they're issues I've ever considered.

document.querySelector() and document.querySelectorAll() are not consistent in selecting the DOM. [...] one is used to select an individual element while the other is used to select a group of elements.

So I'm not sure why this is a problem. Yes, they do different things, but that's normal - you write different functions to do different things. I think of it as querySelector being a bit of sugar for querySelectorAll(...)[0]. If they did the same thing, then there would be no point in one of them existing!

Destructuring the return value from querySelectorAll is definitely something I've never thought of, probably because I don't think it makes sense outside a very narrow use case.

Every time you select something with multiple rules, there's a Venn diagram of DOM elements and their selectors. Unless you're identifying everything with a unique class.

Maybe your e-commerce forms all need some CSRF logic, so you ask something like, querySelectorAll('form.stripe, form.paypal, form.foobarFintech'). You don't want to have to destructure that and iterate through the results, you want a list of relevant forms to bind to.

I'll admit, querySelectorAll falls down a bit here because it doesn't return an array, but it's so common to spread it into one that it doesn't really cause much friction.

Adding a new DSM for things like $select('.post[remove|class=flex bold]') is another odd choice, to me:

First, it's baking an action into the parameter of a function named like a getter. I would rather take the return value from the getter and perform an action on it, or name the function something else.

Secondly, I can't guess from looking at it whether it removes "flex" OR "bold", "flex" AND "bold", or "flex space bold" (i.e. whether order counts).

Finally, $select('.post[5]') is reinventing document.querySelectorAll('.post')[5] except I can't intuit what exception handling there is.

Mike 🐈‍⬛ • Jan 14

the idea that you ship less js because $select is shorter than document.querySelectorAll yet you need to pull in an entire library to use $select is a strange one too

Ayobami Ogundiran • Jan 14 • Edited

$select alone is written in few lines of code and you don't write less code because $select() is shorter — it is far from that but you have to use it to know what I am saying.

In most projects , you will end up writing more lines of code if you don't use $select(). That is why it scales well and still comes with several goodies to enjoy. 🤩

Daniel T Sasser II • Jan 15

This right here folks!

Ayobami Ogundiran • Jan 14 • Edited

First, they do not do the same thing — check the docs I attached for confirmation.

Second, I will say you're right not to deny your experience but if you really want to have a better experience just try it. Then, you will have balanced insight concerning both APIs. So check it out and use it, then let's have this discussion.

Also, you can get returned elements and still do whatever you want with them because $select() always returns all the elements it selects.

It can filter, search the DOM directly and more. And you can use it comfortably, directly, concisely and flexibly in html via onclick, onhover and more.

Parent children input component is a good example of how to use it and you can check its code on codesandbox.

Thank you!

Ben Sinclair • Jan 15

Could you help me out with the source for that preview? It looks like it's a page embedding a ton of minimised scripts.

Ayobami Ogundiran • Jan 15 • Edited

I am the source because I made it.

Live version

Full image:

Note: The library comes with another tool to make JSX work directly in browsers and servers without a virtual DOM or tagged templates. So the image contains a component that uses $select() and $render()

Or what source are you referring to? Thank you.

Ben Sinclair • Jan 15

Sorry, I tried it in a different browser and it worked. The "sandbox" link in the corner was missing in my Firefox (probably an over-zealous adblocker or something). I can see it now.

Ayobami Ogundiran • Jan 15

Thanks for taking your time. I understand ✅

James • Jan 15

1000%. Everything you said is right. This is a weird solution to a nonexistent problem. Dev.to strikes again!

Ayobami Ogundiran • Jan 15

Have you checked it yet? Check it and then review your opinion. The person you're replying seems to have reviewed his opinion.

James • Jan 15

Can you tell me what I'm missing? This is all much ado about being able to destructure, right? Why is that so important? It seems like mostly a preference thing to me, i.e. do you want to have very wide lines or progress stepwise.
querySelector is solved by just not using it, so all that leaves is destructuring and I'm always very dubious of wheels being reinvented.

Ayobami Ogundiran • Jan 16

This is not re-inventing the wheel.

See, $select is an accessory for composition. If you have a component, it is not convenient to keep re-writing every operations.

For example if you want to search a table, you need to write an operation to do that in different cases but you just need a line of code when you use $select.

Check it in action here

Also, $select and $render that come with koras.jsx make it possible to use composition like in React with only vanilla JavaScript which is impossible using querySelectorAll because it is not really composable.

I, Pavlov • Jan 14

So, let's abandon all SOLID principles and move everything from javascript syntax to something else?

//Delete only the instance of .post with index is equal to 2
$select('.post[delete|i=2]');

Is deleting something in a function called select really a great idea? Are we deleting from the selection or from DOM?

It's convenient. But is it useful?

Ayobami Ogundiran • Jan 15

It is both convenient and useful. It does both.

You can filter, search, order and more. Check the docs to have a better understanding of it.

I, Pavlov • Jan 15 • Edited

You're moving away from both JavaScript and CSS by trying to cram too much functionality into a "better querrySelector" while breaking its single responsibility: return nodes matching a CSS selector. For example:

const [posts, comments] = $select('.post, .comment');

The CSS selector '.post, .comment' means "all nodes with either class=post OR class=comment", but instead $select returns all nodes with class=post AND all nodes with class=comment. I realize the result contains the same nodes but I request one list and I get two. Not cool. And if there's a <div class='post comment'> and I get it in both lists, that may or may not be what I expect.

I understand, CSS selector syntax may not be the most intuitive but it's well established and documented. And it would be expected that the same selector returns the same node list everywhere. E.g. '*[something]' is a valid attribute selector but '*[5]' is not and it won't work anywhere else. So the selector isn't CSS and the indexing/filtering isn't JavaScript. Which is why I think it may be convenient but not very useful.

Ayobami Ogundiran • Jan 15 • Edited

Your explanation is faulty.

'.post, .comment' means you want to select all nodes with post class and comment class which is exactly what querySelectorAll does but with some errors but $select() does it correctly.

If you want to select an element with two classes like 'div class='post comment' , you will use '.post.comment'; that is, a tag with both post and comment classes. That is how to use CSS selector.

If your CSS selector query is correct, then it will work in $select(). Maybe you should check CSS documentations for reference.

It seems you're misusing CSS selectors because $select works exactly like querySelectorAll but without its error.

*[something] is meant to work in JavaScript but not in css and standard CSS selectors work as expected. So your concern is not necessary.

Filtering, search and co use JavaScript behind the scenes so they're JavaScript. Everything works well as you would expect them in css or JavaScript.

$select() is designed to work in JavaScript and also works with all standard CSS selectors.

Thanks for the comments.

Ben Sinclair • Jan 15

I think there's a confusion of "and" and "or" terms here.

'.post, .comment' means select all nodes with the "post" class, plus all nodes with the "comment" class". We could phrase this either way in English which makes it a bit tricky to have casual comment threads about it without tripping up.

Ayobami Ogundiran • Jan 15 • Edited

Are you telling me that is not what you do in querySelectorAll for multiple selectors? querySelectorAll only has some errors but $select() fixes them.

Why do you want to criticize $select() for making what querySelectorAll fail at work well?

I, Pavlov • Jan 15

The CSS selector list (,) selects all the matching nodes. A selector list is a comma-separated list of selectors.

[(developer.mozilla.org/en-US/docs/W...]

So yes, you're correct, it's AND but it's one resulting list. When I specifically want to process all matching nodes at once, I use selector list. That's the meaning of comma in CSS. In $select comma has a different meaning.

I think it will be cleaner/more consistent if $select returned multiple lists when passed multiple selectors and one list when passed a single selector list, like this:

const allTogether = $select('.post, .comment, div, #main, [attribute=value]');
const [posts, comments, other] = $select('.post', '.comment', 'div, #main, [attribute=value]');

I understand you use JavaScript behind the scenes, but document.querySelectorAll('.post')[6] is standard array indexing syntax, something all JavaScript developers are familiar with. $select('.post[6]') is neither standard JavaScript, nor standard CSS. It's valid JavaScript but if I need to use a variable instead of literal, it gets ugly. I understand there may be performance gains from returning faster after finding the n-th element in a large document. But CSS already has the powerful but awkward :nth-child() and JavaScript has .filter().

On a personal note, the quotes around "software engineer" on your github profile make it look like you're not confident you're a "real" software engineer. Which you are, and a good one. Cheers.

Ayobami Ogundiran • Jan 15 • Edited

If you have checked the documentation, you would realized that is exactly how it works.

If you get just an element, it returns only the element just like you said.

Now, give me my flowers that have already done it before you say it.

This is why I tried to refer people to use the tool first so that we can have conversations that actually help.

What you raised, in this reply, shows you now have a balance view. And I know JavaScript has filter but it has nothing to do with the DOM. This one filters DOM elements directly after selections. Doing it with JavaScript is not as comfortable.

Also, I will look into what you said further to see if I can improve the tool further with you suggestions.

Thanks! Use the tool because it works exactly as you expect.

bardsley • Jan 16 • Edited

I’ve checked the docs and I think a function named select that deletes things is a terrible idea. Naming things (and caching) is hard but this is a really bad example of doing it wrong. A function should give some indication of what it does from its name. Yours does not. Sorry thumbs down from me

Ayobami Ogundiran • Jan 16

Have you used it? Use it and see how your opinion changes. Thumbs up.

Ben Sinclair • Jan 15

I would be unsure what $select would return in a query such as that. Does it perform the action before or after constructing the array of elements to return? There are a lot of readability issues with combining actions like this.

Samuel Rouse • Jan 14

I appreciate the willingness to try something new, but the divergence from the CSS selector specification makes this difficult to recommend. It is a new but overlapping DSL with CSS, and it moves a lot of functionality into multi-purpose strings which breaks many core developer experience recommendations:

Single-responsibility – The selector string can get an element, an array, an array of arrays, can filter to a specific element, and can modify or remove elements. We can't look at the function being called to know what will happen; we have to reason about the selector string.
Reusability – Actions can be tied into the selectors, so we can't necessarily create reusable functions to take a selector and perform a series of actions on it, because the selector itself might do work.
Discoverability – Developers can't see the methods on a utility or return object, they have to internalize the rules of the library. Rather than a jQuery $('.code').attr('id', 2); you have $select(".code[add|id=2]"); This also reduces the ability for tools like IntelliSense and ESLint to provide coding support and improve developer efficiency and accuracy.
Consistency - $select appears to return an element for a single result like querySelector. This seems like a bug factory to me. The developer must guarantee the selector count to know the return type, or add logic to test for it, negating the benefit. querySelector and querySelectorAll serve different purposes, and this eliminates the developer cues that would tell you which output type to expect. It seems most examples navigate around this by using multiple selections to ensure an array response?

It would make more sense to me if $select accepted more arguments. Rather than the comma living inside the "selector" string and serving a different/overloaded purpose than the standard CSS comma, this would provide equivalent functionality and, in my opinion, be more consistent with both CSS and clarity of the destructurable result array. I have three argument selectors passed into the function, so I will get an array of three results back.

const [audio, posts, comments] = $select("#audio", ".post", ".comment");

Thank you for posting your thoughts and ideas. It's interesting to hear other perspectives!

Ben Sinclair • Jan 15

Yes, according to the docs, $select returns a single item, an array of items, or null, depending on matches. Using querySelectorAll always returns a list, so you don't have to check for nulls, and if you convert it to a regular array you can iterate as normal even if the array is empty, which makes querySelectorAll the clear winner for me in this particular use case.

Ayobami Ogundiran • Jan 15 • Edited

What will querySelectorAll return if it matches nothing?

How would it work if you use multiple selectors with it? querySelectorAll has a bug and it won't work.

See, check the docs for querySelectorAll, you would realize it is meant to do multiple selections but it doesn't work because it is faulty but $select() fixes it.

Thanks!

Ben Sinclair • Jan 15

It'll always return a NodeList - an empty NodeList if it matched nothing. It has a predictable return type.

Ayobami Ogundiran • Jan 15 • Edited

Now, you're raising something that is worth checking. That is why I refer people to check the tool first.

I will check this out and see how I can improve the tool with your suggestions.

What are you suggesting would be a predictable return type in this case? And how is this one not predictable depending on your selections?

Remember, you're selecting multiple different thing. So the corresponding response should determine the type that is returned.

You won't select with an #id and expect to return an empty array when nothing is matched.

So, please suggest in your opinion what to return to have consistent type because $select returns consistent types already. Let me understand your suggestions by digging deeper.

Thanks for taking your time.

Ben Sinclair • Jan 15

If something is returning a set of results, I personally prefer that it always does so.

For example, if I search for .post and there's only one on the page, then with querySelectorAll I still get a NodeList back, so the same code which works for a multiple results works for a single one. That means I don't have to apply any conditions to check whether it's an object or an array.

A lot of systems work the way you've implemented it (I'm looking at APIs in particular) but it adds a step we don't really need.

I don't really like to use querySelector because I have to do a null check. querySelectorAll does the same thing and is consistent. I can then choose to take the first result or check whether the result is empty, and I have the extra info to check whether multiple results were returned when I only expected one.

So far as I read, $select returns consistent types (an object for a single match, an array for multiple selectors, an array for multiple matches of a single selector, an array of arrays for a mixture), but since this is dependent on the contents of the DOM at the time, I can't look at the code and know what the return type will be.

In particular, if I come to change the selector in the future as part of a theme update or something, I have to use more brain to figure out whether I need to update the code because the variable might change type.

I think if I'd tried to do what you're doing, I'd have made an explicit destructurableQuerySelectorAll function to address the issue you first mentioned without bundling in extra functionality.

I'm also rarely, if ever, going to use #ids in my HTML. I'm going to use classes even if something only appears once, and [data-foo=bar] attributes if their purpose is purely javascript. By nature, these are all things that are legal to repeat in the code, so as far as my code (or a linter) is concerned, the way I process the results will always be the same.

Ayobami Ogundiran • Jan 15

Thanks for the detailed reply. I will definitely use some of your suggestions to make it better.

Cheers!

Ayobami Ogundiran • Jan 15

Let me address your comment by saying $select() does everything you have mentioned better than querySelector and querySelectorAll. You just need to use it to find out. Check it out in the library.

Joshua Amaju • Jan 15

This seems like a skill issue, a lack of understand of Javascript and best practices.

If you want people to use your stuff, maybe you should actually engage with their objections and questions instead of just telling them that they're wrong and they should go use your stuff.

Ayobami Ogundiran • Jan 15 • Edited

Skill issue, what? Scratch that! People can object based on biases without using a tool and that is okay.

Our argument will be more reasonable if they have a balance view of the tool first. Arguing without understanding how a thing works is unnecessary.

For example, they said reusability but the tool is reusable. It returns elements they can manipulate further but how would they know without using the tool? That is why I said they should check it out and come back to have a discussion after that.

I noticed a person that checked it now has to raise opinions that are not correct judging from general standard after realizing the tool actually works.

Even when they have genuine concern, it is inaccurate without using the tool.

Another thing is they said single responsibility — are they referring to $select or the query passed to it?

Each part of the query does a thing which you can easily reason with — $select() is just a processor. Just like you won't expect a JavaScript engine to not process several functions, you won't expect a query engine not to process several queries.

But each part of a query does a thing.

And for your information, there is no best practice, we only have practices that worked for some people in their codebases and they tried to generalize them.

Let me say this again, go check it out and you will understand why I direct people to check it out before arguing with them.

Thanks

Joshua Amaju • Jan 15

Even if they're wrong, you're asking people to invest their time on your stuff and you can't even do the bare minimum of engaging with them in good faith.

And for your information, there is no best practice, we only have practices that worked for some people in their codebases and they tried to generalize them.

That's is the definition of best practice.

It's seems you're not open to new information. I doubt you'll achieve your aim with your attitude here. Maybe some engagement on this article, if that's your goal.

Ayobami Ogundiran • Jan 15

First, I am referring people to check it out out of good faith not to waste their time arguing on things they don't know yet

It is like me arguing with people living in New York city after showing a picture of it. How realistic will my opinion be without visiting New York city?

Yes, they raised their cases but the cases are exactly what the tool does and I told the tool does what they raised and direct them to check if for confirmation.

And people are now raising good concerns.

Let's leave best practices aside because that is another unending argument.

I hope you understand my view now?

And people are actually checking it and now raising genuine cases which they couldn't have raised without checking the tool.

I get your points anyway. Thanks!

Perry Rylance • Jan 15

So, jQuery but without the established standards or maturity. I don't want to discourage you but this isn't something I'd recommend people adopt. Keep using it and you'll find out why. Happy coding!

Ayobami Ogundiran • Jan 15 • Edited

Thank you.

The first error in your opinion is that it can do whatever jQuery does that is embedded in browsers and more.

You need to use it so that you have a better understanding of what $select() is.

If you have not used it, your opinion won't be accurate . So you had better check it out to have a balance idea of how it is different from querySelectorAll.

sirjaf • Jan 15

Well done my brother. Keep it up, don't let tech bros talk you down. These are same tech bros who said tailwind isn't going anywhere but today it's all history. Keep pushing for people to try it, when they try it they might start using. Carry go my brother. NB: Best of luck. If there is any constructive criticism, take it onboard and improve your tool. Forget about the nay sayer

Ayobami Ogundiran • Jan 15

Thank you for the support and inspiration.

I really appreciate it. Thanks!

Mohamad Yahia • Jan 15

So just jQuery but with a weird syntax to delete or modify items.
Cool.

Ayobami Ogundiran • Jan 15

It is more than that. You will love the syntax. Just try it out.

Wéri Boni • Jan 15

I didn't even think about that before. But when I was looking for an element or a bunch of elements to select, I can always add a class. But I see the whole point here. I'll save lots of structuring works and there is less work to do.

Ayobami Ogundiran • Jan 16

Now, you get the point.

Taufik Nurrohman • Jan 15 • Edited

Until you know that the underlying method contains document.querySelectorAll() as well. A document.querySelectorAll() with added complexity.

Oowww… that’s hurt!

Ayobami Ogundiran • Jan 15 • Edited

Then? Is that not how all other tools are built?

See, querySelectorAll has some bugs fixed by $select() and makes manipulating the DOM fun and comfortable.

That is why it is important and needed.

Taufik Nurrohman • Jan 15

IMO, even the oldest jQuery is better because it does not require me to learn new CSS syntax as in the $select() argument.

Yes it simplify things, but before users are able to use the tool it requires them not only to learn the JavaScript part but also to learn that added-complexity CSS selector. That’s a double tasks:

I want to select thing and add class to it. Okay I will learn to use that $select() function.
Okay, now I will learn that not-so-CSS syntax to be able to use the tool.

Ayobami Ogundiran • Jan 15

No. Even if you have to learn it, you learn it at a glance because it uses what you already know.

Once you understand CSS selectors and querySelectorAll, you already know how to use $select.

Miloš Maran • Jan 15

I'm sorry, but this entire post reads like an ad for your library - especially when combined with your un-argumented "you're wrong, go try it" responses to legitimate comments

Ayobami Ogundiran • Jan 15 • Edited

No, it is not. It is a way of sharing ideas with like-minded people and learn from them.

I either pointed out the fault in people's arguments or let them know the tool already solved the issue they raised.

I did so for us to have genuine argument for everyone to pick one or two things.

It is done in good faith but not ads. Thanks for the view.

Leandro Falanga • Jan 15

Nice workaround. Congratulations! Destructuration is the most powerful feature.

Ayobami Ogundiran • Jan 15

Thank you!

leob • Jan 15

The title of this article suggests a bit that there's something wrong with querySelector, and that's why you're not using it anymore (and we shouldn't either) ...

That's not really the case IMO - the point is you've developed a little utility lib which you like using, and you prefer using that now instead of querySelector ...

That's fine of course, and it's also fine that you share the lib that you developed, but I feel that the title of the article is a little bit clickbait-y ;-)

P.S. I rarely use querySelector either - sometimes I use jQuery, in other cases I use React or Vue, or another framework where there's no need for direct DOM manipulation.

Ayobami Ogundiran • Jan 15 • Edited

No, I didn't intend to drive clicks; something is actually wrong with it. It has some bugs that are fixed in $select plus the other cases I raised.

And by the time you use $select, you will practically and emotionally relate with my claim.

P.S: If you use React or Vue, you might like $select and its friend $render because they make it possible to use JSX in browsers and servers without a virtual DOM or tagged templates.

leob • Jan 15 • Edited

Seems that a large part of the commenters doesn't agree with your take that querySelector has "bugs", but okay ;-)

If you developed a handy utility lib and want to share it with us, great, but the way you present it still comes across a bit as click bait ... but hey never mind, as I said I'm using jQuery or React/Vue and rarely querySelector, so I don't really have skin in this game ... anyway, thanks for the effort, have a nice day!

Daniel T Sasser II • Jan 15

I feel like creating a library to replace these functions is over kill.

Ayobami Ogundiran • Jan 15 • Edited

It is okay to feel that way but when you consider the repetitive functions you would write to achieve the same purpose and every other things; you will realize $select is a better option especially for composition and you can use it directly in html with events like onclick etc.

I want you to know $select is an accessory for composition to be used in a component.

Koras.jsx is meant to make JSX possible in browsers and servers without tagged templates or a virtual DOM. When $select is used in a component, it becomes more useful.

That is why I direct people to the docs so that they can experience it first hand.

Daniel T Sasser II • Jan 15

Well put. Thank you for your explanation. Although I have other more precise and custom methods for achieving this, it seems you have came up with the way you find efficient.

Dave Stewart • Jan 15 • Edited

I'll always support a developer's right to build something new, but it seems you've just reinvented jQuery but with a more opaque, less extensible, string-based API which will lack any tooling or IDE support.

Consider:

// koras.jsx
$select('.post[delete|i=2]')

// jquery
$('.post').get(2).remove()

If you haven't already, take a look at jQuery's universal selector function $(), the Sizzle library that powers it, it's internal collection (effectively all selections are converted to internal arrays), chaining, filtering (the equivalent of your DSL), and all other functionality (traversal, events, etc) which are effectively plugins on the core code.

Also, check out libraries like Zepto, Cash and Umbrella JS which attempt to be more lightweight versions, yet still extensible.

And, bear in mind that jQuery was released nearly 20 years ago; amazing, really!

Alex Lohr • Jan 15

Oh, so you wrote another partial jQuery clone. Sorry to bust your bubble, but this is 2025 and we have modern frontend frameworks (react, angular, vue, svelte, solid, astro) to render DOM and keep its references so we only ever have to manually query dom nodes for our initial render target - and we can use getElementById for that.

Ayobami Ogundiran • Jan 15 • Edited

My friend, thanks for bursting my bubble but now, let me also burst your bubble.

You can't use all of the frameworks you mentioned without a transpiler, compiler, virtual DOM or tagged templates.

Now, koras.jsx — $select and $render — makes it possible to use JSX in browsers and servers without a virtual DOM or tagged templates.

Peter Galiba • Jan 15

I don't see how it handles attribute selectors, and why the operations are not further arguments instead of something that looks like an attribute selector.
The other thing is, that I did not see any unit tests for the said $select and without that, you cannot say it does everything that querySelectorAll does.

Ayobami Ogundiran • Jan 15 • Edited

Let me start with unit test.

The unit test is coming soon because I had to prioritize getting it done first as the problem I solved — using JSX without a virtual DOM or tagged templates in browsers and servers — is generally considered impossible by frontend/js engineers.

And it is impossible to write unit test for what no one, including myself, understood. So I had to focus on understanding it and finding a way to solve the problem first.

Now that the problem is solved, I will work on the unit test.

For how it handles attribute selectors, check the picture attached which is from the docs.

I have considered everything before bringing it to the public but if you find any error, please let me know.

The operations are not further arguments because you might need to put each argument in a string and we developers tend to not like strings in such a case.

If you have a way to use them as further arguments without passing all of them as strings, please let me know.

Freek • Jan 15 • Edited

In larger projects your $select will become far less appealing and would even introduce more inconsistencies in the code.

There's a reason why there's querySelector and querySelectorAll: It's because both functions return a different type. querySelector always returns Node | null whereas querySelectorAll always returns NodeList. Regardless of the of the input. This is a good thing because you, as a programmer, do not need to check whether your query returns null, a Node or a NodeList. Having two separate functions eliminates the guesswork.
querySelector and querySelectorAll don't live in document. Rather, they're methods of Node. Meaning you can call these functions on other DOM elements as well, allowing you to query only in specific sub-sections of the DOM. This is excellent for performance reasons, as the browser won't have to go through the entire document for every query. It also means I can pass my queried Nodes to other functions who can then perform subsequent queries.
```
// Get the second form in the document.
const form2 = document.querySelectorAll('form')[1]
validate(form2)

function validate(formEl) {
    // Query all the inputs in this specific form element.
    const inputs = formEl.querySelectorAll('input')
    // etc...
}
```
I believe $select does not support something similar?
The queries we write in querySelector and querySelectorAll follow the selectors syntax from the CSS spec. The fun thing about CSS? Counting starts at 1. Whereas your $select function allows for JS array syntax ([0]) which starts counting at 0. You now cause inconsistencies by combining two different cultures into one:
```
const hmm = $select('div:nth-child(1)[0]')
```

If people are so bothered by writing the long queryBlahblah method names, never want a NodeList and are hypnotised by the idea of destructuring, then I've got 11 lines of code to ease their mind:

Node.prototype.$ = function (selector) {
  return this.querySelector(selector)
}

Node.prototype.$$ = function (...selectors) {
  const results = selectors.map((s) => Array.from(this.querySelectorAll(s)))
  return selectors.length == 1 ? results[0] : results
}

export const $ = Node.prototype.$.bind(document)
export const $$ = Node.prototype.$$.bind(document)

const form2 = $$('form')[1]
const [inputs, selects, textareas] = form2.$$('input', 'select', 'textarea')

(I do not condone this code, btw)

Sorry for the dogpiling :)

Ayobami Ogundiran • Jan 16

The issue of consistent type can easily be adjusted in $select if that is better. Why would you prefer return type of empty array instead of Null when nothing is found?
You can also used querySelectorAll on elements selected with $select. It just that there is no reason to do so as you can select the nested elements together.

$eelect caches the DOM, so it doesn't hit the DOM every second.

.post[1] is meant to simulate what querySelectorAll does but not css. If you want to select by using css, just use css and it work.
$select is more useful for composition. That you can easily use it in a component.

Thanks! Anyway, I will look into what you said to see how to use your suggestions to improve the library l.

Shaktijeet Sahoo • Jan 15

Okay. If I'm not wrong you just head butter into a DSA strings lesson and jumped right into developing a library that "YOU" think is buggy.

Let's say you are right. And somehow I installed $select. Let's compare syntaxes.

// I need to add class foo in only the first instance and bar in the others

// querySelector
const elem = querySelectorAll(".post"); // this gets me all the posts, empty NodeList if none present
elem[0]?.classList.add("foo")
for (let i = 1; i < elem.length; i++) elem[i].class list.add("bar")

// $select
const elem = $select(".post"); // this gets a single element? an array of elements? null?
if (elem) {
    if (Array.isArray(elem)) {
        elem[0].classList.add("foo");
        // Rest of the code to add bar to class list of others
    }
    else elem.classList.add("foo");4
}

So what exactly are you solving here? Now your response will be goading me in to trying out your library and set the classes using strings, but now I want to log the string values of the elements. Do I run another select query? Yes I would have to. And I hate repeating code, be it of any kind

Ayobami Ogundiran • Jan 16 • Edited

Your code is not correct. What you would have done is:


js
const post = $select(".post[add|class=foo]")

Now, you see the difference ✅

Đăng Tú • Jan 16

Why are you introduce an issue that has never been one before mate? Do you know what reasons drives me away from jquery? One of them is your $select(). It messes up the plural system of English and without proper doc, it is even more confused. Now you bring back a similar problem... queryselector is good mate.

James • Jan 15

This is completely unnecessary and "solves" a problem that doesn't exist. Maybe just stop using querySelector since that's the actual issue you've cited. If you need one element, use getElementById. If you need multiple elements, use querySelectorAll. Easy.

Tomas Rainbolt • Jan 15 • Edited

I’m not sure why I would want to learn how to use some seemingly hacky tool to do what’s natural in JavaScript already. Looks to me like you would have been better served to not jam everything into $select and instead make distinct functions so that it’s clear, you’ve lost a lot of people on that. You also don’t do yourself any favors by presenting your solution and basically make everyone feel stupid for dismissing it on the contexts that they don’t have issues with querySelector/All or they don’t like how it’s difficult to read what’s happening in your $select alternative. I don’t think you were ready for people to disagree because you spent time solving something for your use case and couldn’t possibly imagine how someone else might not find it useful.

Peter Lamb • Jan 16

This a non-existent issue. Both querySelector and querySelectorAll have different meanings for a reason, which is why they are separate methods. If you want to unify, just use querySelectorAll, convert to an array aand destructure the result, then you can encapsulate that if you wish. It is not rocket surgery.

Ayobami Ogundiran • Jan 16

It solves a problem. It makes it easy and possible to use JSX without a virtual DOM and tagged templates especially in a component in browsers and servers which querySelectorAll can't do.

It is only by using it one can realize how useful it is.

Sefunmi • Jan 15

This article is interesting.

I would never hate on a programmer who took time to work on this kind of project. Especially not a Nigerian, God forbid. It takes a lot to put something it in the world (with docs!), and I really hope you grow and become better in your craft.

But Google put this article in my home tab, and I can't not comment on hubris.

It is a rule of thumb to ship less JavaScript where possible and $select() makes it feasible while dealing with DOM selection. $select() is preferable to document.querySelector() and document.querySelectorAll() at scale because it is more concise and less repetitive. The more elements you select, the less you repeat selection with $select().

Your library has an index.js file that is 1492 lines long. That is not less JavaScript. With one function:

const select = (s) => [...document.querySelectorAll(s)]

I would already have 75% of its functionality.

Using document.querySelector() tends to create more surface area for bugs to hide compared to $select() because of its support for DOM destructuring and multiple selections.
const audio = document.querySelector("#audio");

const posts = document.querySelectorAll(".post");

const comments = document.querySelectorAll(".comment");

// OR

const [audio, posts, comments] = $select("#audio, .post, .comment");

Is there a reason you cant do:

const [audio, posts, comments] = [...document.querySelectorAll('#audio, .post, .comment')]

It's not that much longer, if the character count is that important.

$select() reduces the number of lines of code to write to select elements and so reduces the surface area for bugs to hide. That means bugs are more likely to be discovered comparatively faster while using $select().

I could make the argument that your library would introduce more bugs, but eh.

You can't append an array of elements generated by $select() to another element like element.append(arrayGeneratedBy$Select) because the DOM expects NodeList.

Again, you can just do element.append(...arrayGeneratedBy$Select). This is nitpicky, but it is the main issue I have with this post. You are presenting features that were agreed on by specification authors as "bugs" and pushing your library as a solution to a problem that does not exist. If anybody is working with DOM nodes directly, they are either doing it because they really want to, in which case a library would just irritate them, or they are already using jQuery.

It is possible to claim that querySelector() or querySelectorAll() is faster than $select() with about one millisecond on average but $select() wins it back with interests at scale.

You made custom versions of setAttribute, filter, sort, and jsonStringify in JavaScript. In what world would these ever be as efficient as the C++ running in v8? I call bs in the "one millisecond" claim.

Another thing, I don't like the name. $select() can retrieve elements from the DOM, but it can also delete elements or mutate elements to add/remove attributes. That's not a selection. At least querySelector and querySelectorAll do one thing each.

I went through the library, and I have several more issues, but they are related to the framework implementation and therefore completely irrelevant to this post.

I don't know if this is click-bait/rage-bait, or you genuinely think you've created something mind-blowing. Either way. I regret to inform you that you have not.

Freek • Jan 15

Is there a reason you cant do:

const [audio, posts, comments] = [...document.querySelectorAll('#audio, .post, .comment')]

This does give a different result than $select would, actually. In $select it would be 3 different queries, resulting in 3 separate arrays (or elements). Your querySelectorAll combines everything into a single array, without any guarantees of order. If an element with the .post class preceded the element with id #audio in the DOM it'd be assigned to the audio constant, for instance.

Aad Pouw • Jan 15

It looks like you don't work with modules, because if you do and you do it on the right way, there aren't any issues with that.
The way I do it:

In my folder 'factory' , In there I have a file called 'functions.js' and within I have async function that is doing that for me "elQuery(elem,false, parent)" ,the second param (when true is for 'all') and the last param is optional. Also I have an async function for a live query, called "getClassHelper(elems,parent)". This functions I mostly use at the beginning of my stack in a file called 'initObjects.js'. The data here I pass allover where needed. 'in future time I might come up with a how/to'.

Ayobami Ogundiran • Jan 15 • Edited

I work with modules but $select does more than what you said above.

You need a line of code to fitler a table and co. in $select. A lot of burden is lifted.

Sergei Kirjanov • Jan 15

It is really nice, that you are creative and even made your own selector language. I like to make such things too.

But let me say a few notes on consistency, as I'm one who have seen big projects.

1) It seems inconsistent to use 'post[delete', because you are trying to delete dom-representation-of-post. But you really want to delete post itself, and keep the representation in sync automatically.

2) TS and IDE can help a lot in finding bugs. But they does not understand your great new selector language. $select can return any type, and they can not help.

Ayobami Ogundiran • Jan 16

Thanks. The case of type is something straight forward to address. $select type is consistent.

It only return null when a group of elements are not found. That is the only time you want an empty node list and that is so easy to fix.

I will work on it. Thanks.

Sergei Kirjanov • Jan 15

const [posts, comments] = [$all(".post"), $all(".comment")]

PeteC • Jan 15

I think you omitted one important line when writing your library and this post:

import { humility } from "./basic-human-traits";

Ayobami Ogundiran • Jan 15 • Edited

Oh, please let me learn why you said that. And if it requires direct messages, I am comfortable either ways.

Thank you.

Charles • Jan 15

This would be way less annoying if you were just transparent about plugging this library you wrote instead of using a click bait title that implies QuerySelectors are useless

Ayobami Ogundiran • Jan 16

Yeah, it is useless when you start using $select.

Andy Wright • Jan 15

Nonsense!

Simon Li • Jan 16

Is there a library called jQuery?

Ayobami Ogundiran • Jan 16

This is not jQuery in operations.

S David Prince • Jan 15

I don't think
Someone like me would like to pull a whole library I prolly won't make use of rather than selecting.
Mxm
Learnt from this and Thanks for sharing

Ayobami Ogundiran • Jan 15 • Edited

I understand you're making this judgement without checking out the actual tool.

And that is okay but this is a project you will definitely love to use if you check it out.

Matthew Broatch • Jan 15

If someone's merge request added a library because they didn't like querySelector they'd be laughed out of code review anywhere I've worked