Why I won't use querySelector again.

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 document.querySelector() and document.querySelectorAll(). The DOM methods make accessing the DOM a lot better.

Recently, I had some experience that practically proved to me that using both document.querySelector() and document.querySelectorAll() is sticking to the distant past while missing many juicy features in Javascript.

Using document.querySelector() and document.querySelectorAll() means you can't destructure the DOM, access the DOM consistently, simplify multiple selections and reduce typing difficulties. Now, let's dive deeper so that you can realize all you're missing already.

But wait! If you don't really understand what querySelector() and querySelectorAll() are, and you want to learn more about them; check out the video tutorial below: JavaScript DOM manipulation

Inconsistent methods

document.querySelector() and document.querySelectorAll() are not consistent in selecting the DOM. One selects the first instance of the target selector while the other selects all instances of the target selector. That means one is used to select an individual element while the other is used to select a group of elements.

So you can't use both interchangeably. You have to keep on switching from one to another depending on what you want to select.

// Select the first element of the class .post
const post = document.querySelector('.post');

// Select all elements of the class .post
const posts = document.querySelectorAll('.post');

Now, let me show you a better way to do it. I just built a UI library called koras.jsx that comes with $select()
which can be used in place of both document.querySelector() and document.querySelectorAll() in JavaScript and below is how to use it.

//select all instances of class .post
const posts = $select('.post');

//select the first instance of class post
const firstPost = $select('.post[0]');

//Doing the same with querySelector

const posts = document.querySelectorAll('.post');
const firstPost = posts[0];

How cool is that? And it just works for the use cases of both document.querySelector() and document.querySelectorAll().

Selection by index

You can select an element among grouped elements at any position.

//select 6th instance of class post
$select('.post[5]')

//select 7th instance of div elements
$select('div[6]')

Deleting elements

You can delete elements with $select() like:

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

//delete all instances of .post with index greater than 2 
$select('.post[delete|i>2]');

Adding attributes

You can add attributes to elements with $select()like:

$select('.post[add|class=hidden]');

$select('.post[add|style=1px solid red]');

$select('.post[add|id=2]');

$select('.post[add|class=flex bold]')

You can remove attributes from elements with $select()like:

$select('.post[remove|class=hidden]');

$select('.post[remove|id]');

$select('.post[remove|class=flex bold]')

$select('.post[remove|style]');

DOM destructuring

DOM destructuring is one of the features shipped in es6 but you would be surprised you can't destructure the elements selected with document.querySelector() and document.querySelectorAll().

Not working:

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

Solution:

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

Can you see that? document.querySelectAll() doesn't support DOM destructuring. That means you're missing out on destructuring the DOM. No! That is not cool at all so you have to start using $select().

Repetitive methods

Using document.querySelect() or document.querySelectorAll() forces you to repeat themselves unnecessarily because they don't support DOM destructuring and that makes it a bit messy to maintain JavaScript code.

Won't work

const [audio, posts, comments] = document.querySelectorAll(".audio, .post, .comment");

So you have to do:

const audio = document.querySelector("#audio");

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

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

Can you see how repetitive that is and how it will make it a bit messy to maintain your codebase at scale?

See, you can do the same using $select() like below with ease:

Solution

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

Difficulties in debugging DOM selections:

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");

$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().

Ability to use all array methods.

Elements selected with querySelector can only work with forEach but not map(), filter() and co.

$select()works with all array methods by default unlike document.querySelectorAll() which requires some workarounds that may lead to unnecessary repetition and complexity at scale.

Maintainability

Maintainability is always revolving around ease of use, brevity and consistency. Any codebase that is concise, consistent or easy to use tends to be maintainable. It is messy to maintain repetitive, and verbose code because you have more surface area to look at especially while fixing a bug or building a feature.

Shipping Less JavaScript

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().

Appending or prepending array of elements.

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

Still, you can tell $select() to disable all of its superpowers by passing false as a second parameter to it.

//superpowers are on by default but you can pass false to off it.

 $select('.post', offSuperpowers);

 $select('.post', false);

Now, it will return a normal DOM NodeList[] that is appendable and prependable.

$select() can do that

You maybe curious if $select() can do everything document.querySelect() or document.querySelectorAll() can do. Yes! It can do whatever they do. $select() can do it all. It can use tagor css selectors and do every other things query.querySelector()can do.

Is document.querySelector() any better?

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 still need to learn to use querySelector because understanding how to use it gives you a chance to build something useful on it just like $select(). I am able to build $select() because I truly understand how it works.

I have made a tutorial on it. Check it out below: JavaScript DOM manipulation

Why I won't use querySelector ever again

By supporting DOM destructuring and enabling array-based selections, $select() proves to be a valuable addition to my toolkit. It not only improves the readability of my code but also minimizes the surface area for bugs, making debugging a more straightforward process.

In the search of maintainability, brevity, and consistency, $select() is a good choice for DOM selection, showing a step forward in the evolution of JavaScript development.

As we continue to adapt to the evolving JavaScript ecosystem, using tools like $select() ensures that we keep making our code more concise, readable, and maintainable.

Comments

[Ben Sinclair]

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 🐈‍⬛]

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]

$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]

This right here folks!

[Ayobami Ogundiran]

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]

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]

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]

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]

Thanks for taking your time. I understand ✅

[James]

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

[Ayobami Ogundiran]

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

[James]

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.

[I, Pavlov]

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]

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]

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]

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]

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]

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]

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]

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.

[Ben Sinclair]

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]

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]

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]

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]

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

[Ayobami Ogundiran]

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]

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]

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

Cheers!

[Ayobami Ogundiran]

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]

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]

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]

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]

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]

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]

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.

[Mohamad Yahia]

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

[Ayobami Ogundiran]

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

[sirjaf]

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]

Thank you for the support and inspiration.

I really appreciate it. Thanks!

[Taufik Nurrohman]

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

• github.com/codingnninja/koras/blob...
• github.com/codingnninja/koras/blob...

Oowww… that’s hurt!

[Ayobami Ogundiran]

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]

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:

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

[Ayobami Ogundiran]

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.

[leob]

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]

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]

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!

[Miloš Maran]

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]

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.