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 ...
For further actions, you may consider blocking this person and/or reporting abuse
I'm looking at your initial issues and I don't think they're issues I've ever considered.
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 forquerySelectorAll(...)[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 DSL 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 reinventingdocument.querySelectorAll('.post')[5]
except I can't intuit what exception handling there is.the idea that you ship less js because
$select
is shorter thandocument.querySelectorAll
yet you need to pull in an entire library to use$select
is a strange one too$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. 🤩
This right here folks!
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!
Could you help me out with the source for that preview? It looks like it's a page embedding a ton of minimised scripts.
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.
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.
Thanks for taking your time. I understand ✅
1000%. Everything you said is right. This is a weird solution to a nonexistent problem. Dev.to strikes again!
Have you checked it yet? Check it and then review your opinion. The person you're replying seems to have reviewed his opinion.
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.
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.
So, let's abandon all SOLID principles and move everything from javascript syntax to something else?
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?
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.
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:
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.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.
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.
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?
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:
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.
If you have checked the documentation, you would have 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.
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
Have you used it? Use it and see how your opinion changes. Thumbs up.
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.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:
$('.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.$select
appears to return an element for a single result likequerySelector
. 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
andquerySelectorAll
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.Thank you for posting your thoughts and ideas. It's interesting to hear other perspectives!
Yes, according to the docs,
$select
returns a single item, an array of items, or null, depending on matches. UsingquerySelectorAll
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 makesquerySelectorAll
the clear winner for me in this particular use case.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!
It'll always return a NodeList - an empty NodeList if it matched nothing. It has a predictable return type.
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.
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 withquerySelectorAll
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
#id
s 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.Thanks for the detailed reply. I will definitely use some of your suggestions to make it better.
Cheers!
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.
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!
Precisely. Once he gets inconsistent results based on the number of nodes returned, he will realize why this is a bad idea. And once he learns SRP, he will know why this breaks it, and badly.
Please show me how I would get inconsistent results. That would be more helpful. I have tried on my own to figure possible issues and I will appreciate it if you point it out in this case.
$select is structured. Please point out how it is not and rest assured I will improve it based on your suggestions and even give your credit for it.
Anyway, I am not scared of learning because I have been learning for several years. Learning is a source of growth.
Okay, let us take this as an example...
Say I have a dynamic view with 0 - n divs.
What does your $select return when there are...
0 found
1 found
more than 1 found
Advise me of that and perhaps I can show you what I am trying to explain. Use 'div' as your selector.
It returns "null" when 0 element is found.
It returns the only found element
It returns an array of all the elements found.
That is it. I am expecting your response.
That is a serious bug, as you now need to run multiple checks against EVERY call to $select to check what it is returning. That scenario REQUIRES querySelectorAll so that you get an expected response type as you don't know from the outset how many you will get. All you need is a function that wraps querySelectoraall and returns an array, which you can then easily deconstruct. That would be two lines of code and 3 lines for core function. Your code would require about 8-9 lines of code for every call to $select. I am sorry, but that is just a beginner mistake.
And that doesn't include your breakage of the single responsibility principle by allowing deletion in a function that is meant for selection. And changing the selector syntax too. If CSS changed to include that syntax, your code would cease to work.
If you want to see code samples that would vastly improve your code, then I will happily supply them.
Also, what bug is in querySelectorAll or querySelector? I have never found a bug in either. Please elaborate on this "bug".
I appreciate your comment and I have already finalized the case of returning null with someone else in the comment section.
I see many people suggesting using [...document.querySectorAll(".post, .comment")] which will return unexpected result.
I wish I was wrong but it seems MDN docs for it is not consistent with expectations that is why we don't destructure multiple arrays of selected elements.
You will understand my point better when you use $select().
It would be good to try out what you suggest here because you can't destructure querySelectorAll for multiple selections.
I have no idea why you think you can't destructure it. Just write it so that it works for your use case.
You can write a function that converts a NodeList to an array and then you can destructure it with ease.
See how easy that was? A consistent return type of Array for the $$ function, so no unexpected behavior due to the change in return type and easily destructured. The above is 6 lines of code for two core functions that you can use where required and no need to check for null, check via Array.isArray, etc. It just works in an expected, consistent fashion.
Using the above, I'll never use querySelector, querySelectorAll OR $select ever again :D
It is seems you don't get my point. Can you select multiple group of elements with your custom function without any issues? Like [divs, posts] = $$('div, .post');
You should know building what I built I should have tested things like this before arguing with you.
Now, go and test your theory, you might understand why the library is a better option.
If it's a valid CSS selector, then the code I provided will work every time.
If you want TWO discrete sets of elements based on two CSS selectors, then you would use two commands to do that, not one, and it would be folly/undesirable to do that in a single statement without breaking how CSS works.
So, again your library is either breaking CSS selector syntax, or you're simply trying to return two result sets from a single CSS selector. That's not how CSS selectors work, nor how they should work.
Your lack of understanding of the Single Responsibility Principle is not my problem. I'm showing you how to select single elements via a $ function. I'm showing you how to select arrays of elements using $$, which can be easily destructured and it's literally a few lines of code to do so, so the whole "I'll never use querySelectorAll again" statement is pure nonsense.
So long as you use valid CSS selectors, then you'll be fine, but if you don't know how CSS selectors work or how the Single Responsibility Principle operates, then I can't help you any further. Until you understand CSS selectors and SRP, then you won't be able to progress any further and your library will continue to cause you issues in the future. No real software engineer who tries it will continue to use it, given the bugs in it (lack of clear, expected interface for $select and its response, breakage of CSS selector syntax and lack of SRP).
Trust me, I am TRYING to help you understand where you're going wrong, but you don't seem to be able to grasp it, so look back over what I've provided and look up SRP first before responding again.
If you want divs and posts like you've suggested via this broken code:
Then, you should do this instead (using the code I provided):
if you want all of the posts for a given div, then provide that as the root, then get the posts...
You're trying to solve a problem that doesn't really exist and doing it wrong by mixing and matching too many things together. Just because you can write a whole program in a single line of code doesn't mean you should do so. You should always write code for clarity of purpose, first and foremost. Everything else is secondary.
Thank you. I will definitely pick one or two things from your suggestions.
Please add filter, search, ordering and everything $select does to your code and you will get $select.
All the filtering, searching and co added to $select make it more reusable and composable and that is its main purpose.
I don't know why you think I am not heeding your advice. I do. You yourself would tell me to only improve it with your ideas by the time you use $select and $render.
Thank you for taking your time.
You are assuming I don't understand SRP and everything you've said.
Please, I do.
I have worked with it from another angle you're not willing to consider or understand.
$select() in this case is a processor and it only does a thing by processing queries and I make sure people can't do anything else with it except its returned values because SRP.
You're making wrong assumptions
confidently without using a tool. You're trying to help but have you used the tool to have a proper context and come with a case where it has one of the issues your raised? No.
Or you just want me to take your opinion blindly when I have already done rigorous research on what you assume you know better than I do?
Please, I respect you for taking your time but try not to make wrong assumptions that have nothing to do with the library.
I used $select and $render, in combination, to solve a problem generally considered impossible by every JavaScript/frontend engineer. If I have followed every so called best practices blindly like you want me to, I wouldn't have been able to solve the problem.
I am a forever-learner. I have learned from you and others who raised genuine cases but don't expect me to just take your opinion blindly. Never! I have already started my own research based on opinions on this article.
Thank you.
I solved your problem already, without breaking SRP or standard CSS syntax, achieving it with less code and resulting in less code use than your $select does. And it if you wish to destructure the array, you can. If you wish to filter, map, reduce, whatever you need, you can, as it provides every base method that an array provides. There's literally nothing left for you $select to solve. $select breaks CSS syntax, breaks SRP and does not have a consistent return type as it returns null for 0 records, a single object for 1 and an array for multiple results, so it's completely unusable when you don't know how many results to expect.
The only thing you can't do with my code, and you shouldn't anyway, is return multiple result sets from a single invalid CSS selector e.g. 'div, .post'. However, like I already described, you should be doing that with two lines of code, not one, to get two result sets. That's far better coding style, more maintainable and doesn't require all the breakage that you introduced via $select.
I understand you're relatively new to this and you're learning, but you really need to listen to what people are saying to you. They're not all wrong and you're right. It's the other way round, unfortunately. Learn from it and move on.
Anyway, happy coding. Hope you can learn from your errors here and do well in the future!
Don't be condescending please. I am professional with more than 12 years of experience in this field and a lot of achievements under my belts.
Select doesn't break CSS syntax because I am great at system design and nothing of what you said. Please show me an example of a CSS syntax it can't use? You brought nothing but you're still arguing confidently without evidence.
I am not in this for opinion. I am a builder so bring any CSS syntax it violates. I am waiting!
I understand system design so $select is designed to not use its own operations once a query doesn't match its query. So any change in css queries is catered for.
In case CSS adopts div[remove|id], $select will still work because that is a $select query though we can ship another version of the library to use css alternative. So, that is not a problem because no error would be caused.
Please, don't assume I also didn't worry about everything you're worried about why building the tool. I am also a developer who has similar concerns like you do so I always put in efforts in this regard.
See, the part you focus on is not even the important part of $select. You will only understand what I mean if you have to repeat filter function many times.
How will the function you wrote shuffle DOM elements?
$select(.post[add|order=shuffle]);
You said that you have solved my problem, how will you do the operation above with your functions?
Good luck.
You're also emphasizing null check case as something to worry about. No, it is nothing to worry about because it is already fixed. It is a case of returning an empty array instead of Null to avoid null check but you make it look like it is rocket science. It is not that serious please.
And stop assuming what you know nothing about. Use it and bring the errors instead of assuming. Out of curiosity, how did you know something you have not used is unusable under a condition?
If you can't bring the errors here, you opinion doesn't count. If you bring the errors, I will fix them instantly.
It seems you want to prove your superiority but I am not in for that kind of contest.
If you really want to help, use $select first and you will clear your innocence and come up with better concerns and then your opinion will be more important.
Thank you!
I asked you how how $select works. You stated it returns null when no results, a single object when 1 result and an array when more than 1 result. That makes it unusable.
.My code returns an array from $$ regardless of selector, so far better than your lib already.
And given that $$ returns an array, you can map, filter, reduce, reverse or even shuffle, if that's what you need.
Your lack of expected return type is what kills $select dead in its tracks. If you have since fixed that bug then I will happily take another look. But if it still returns , null, singleton or array, then I won't argue any further as that is a HUGE bug in your design that needs to be rectified. Only a beginner would make such an obvious error of judgement. If you're not a beginner, then it is bamboozling that you would do that. But, like I said, if you have fixed that design issue, then I will happily try it out.
And BTW, you have been condescending in this thread to multiple people, ignoring their advice, so I am amazed that you are surprised by people responding in kind.
You asked a question and I responded without trying to play smart because I really wanted to get your message. If not, I would have shifted the goal post.
If you noticed my response mannerism, I addressed opinions like "Your point is wrong" but hardly said "You're wrong" except when I said "You don't understand SoC yet" which was intentional to drive home a point.
For your information, I told the first person that raised the issue of empty array instead of Null that I have fixed it for the next version. If you have checked my comments, you would have seen I admitted they were right that I had updated the code for another version release.
I have definitely picked things to improve the library. And be informed, I am not offended by all you said, sometimes we misread intentions from words.
Anyway, I am still expecting your CSS syntax violation examples.
Cheers!
Let's go back to your own example...
You keep saying that there's a bug in querySelectorAll, which you haven't qualified thus far. What do you expect that selector to return that querySelectorAll is NOT returning correctly, in your view? If there's a bug in querySelectorAll, then I'm sure (in addition to myself) Google, Mozilla, Apple and other JS engine implementation vendors would love to hear about it. If you are expecting it to give you two result sets (you did state that previously), then the problem is not querySelectorAll, but your own expectations, as that should be done in two lines of code, not one. That's just not what CSS selectors are for, nor what they should be used for.
So, if you can explain the bug in querySelectorAll from your view, then perhaps we can figure out why you're so averse to using querySelectorAll or a simple wrapper like the one I provided ($$), which, as far as I can see, gives you every feature you're looking for but in far less code. But, if you're looking for two diverse data sets, from a single selector, then I can't help you as that's not how coding works.
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.
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.
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 and does a thing by processing queries. 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 every query does a thing too.
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
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.
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.
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 me 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 them the tool does what they raised and direct them to check it 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!
So just jQuery but with a weird syntax to delete or modify items.
Cool.
It is more than that. You will love the syntax. Just try it out.
hard pass
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
andquerySelectorAll
: It's because both functions return a different type.querySelector
always returnsNode | null
whereasquerySelectorAll
always returnsNodeList
. Regardless of the of the input. This is a good thing because you, as a programmer, do not need to check whether your query returnsnull
, aNode
or aNodeList
. Having two separate functions eliminates the guesswork.querySelector
andquerySelectorAll
don't just live indocument
. Rather, they're methods ofElement
. 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 queriedElement
s to other functions who can then perform subsequent queries.I believe
$select
does not support something similar?The queries we write in
querySelector
andquerySelectorAll
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:If people are so bothered by writing the long
queryBlahblah
method names, never want aNodeList
and are hypnotised by the idea of destructuring, then I've got 11 lines of code to ease their mind:(I do not condone this code, btw)
Sorry for the dogpiling :)
The issue of consistent type can easily be adjusted in $select if that is better. Why would you prefer return type of 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.
$select 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 works.
$select is more useful for composition. 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.
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
Thank you for the support and inspiration.
I really appreciate it. Thanks!
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.
Now, you get the point.
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.
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.
While that is not entirely true, the other solutions are far less convenient. But even then, what is the issue with that? What should stop me from using these solutions?
What you have there is not JSX. It is just HTML template strings that look like lit-html in poor light and a renderer that re-renders already rendered components. But we do not re-render full components if not necessary in modern frameworks for a reason. If you test your library in the frontend framework benchmark, you'll see why I'm less than excited about that idea.
Have you benched marked it? Do so maybe you will reconsider your opinion once again.
Thank you for the insight. I will look into everything to see if there is anything I can use to improve the project.
And remember, none of the frameworks you mentioned can comfortably work on both browsers and servers at the same time without a lot of issues. Don't even mention React because I built the project so that my students could easily learn composition and best React practices from js before moving to React.
I'm not here to do your work for you. I have superficially read through your code and I see no way your framework can even remotely compete with the faster frameworks.
That's what their related metaframeworks (next, nuxt, svelte-kit, solid-start) are for. Do your research before you make your claims, please.
Why do you assume I have not done my research? See, you are currently criticising the fastest UI framework ever created by man.
Cheers!
More outlandish claims for a framework that had its first commit on github last November. I'm not buying it. If you really did your research, please present your findings in a reproducable way. I don't see a benchmarks directory in your repo nor can I find a benchmark for your framework anywhere else I looked.
Cheers!
I actually like the way you communicated your intention. I will work on benchmarks and add them to the docs.
Now, you see, your suggestion has inspired something meaningful. Thank you!
const [posts, comments] = $select('.post, .comment');
This is terrible. This should have been an array of
posts or comments
but instead you get 2 different lists.This maybe one of the worst api's I've actually seen. If I wanted two different lists, I would make two different calls.
I am guessing whoever came up with this api had a single niche idea in their head and has made a super short sighted decision because of it.
I know your opinion is genuine.
Why should it have been an array of posts or comments but not posts and comments aside from the fact that it is in the MDN docs?
Because you are now going against CSS syntax, it would be like calling all your other method names French.
Could you imagen all arrays in JS being
.map(), .filter(), forEach()
but your one API it would be.carte(), .filtre(), .pourChacum()
And your only response would beread the Docs
orget gud
.Going against the grain will cause frustration. One of the problems jQuery had was also going against the grain with argument order.
array.forEach(item, index, arrayInstance)
vsjQueryArray.each(index, item)
So no method reuse was possible unless you wanted to do argument integrations.As for
forEach
being the only method that works, and notfilter
ormap
, you may wish to look again, since we now have Iterator helpers, which gives us the additional methods of.drop()
,.take()
,.flatMap()
,.some()
,.every()
,.find()
and I am sure there are more , we have all the methods at our disposal.querySelectorAll()
is a lazy list, so it only gets the next value when it's required, and forgets the items it's already processed. So the memory footprint forNodeList
fromquerySelectorAll()
is miniscule, especially if used against hundreds of thousands of dom elements. (Though, as you may guess, the browser would be starting to struggle by that point also). But it's designed to work at scale instead of only working for small lists of a hundred or so.I will definitely use everything you said to improve this but please use querySelectorAll to select multiple instances of posts and comments ('.post, .comment') and see what happens, then you will also understand my point too.
Please try it.
Tried it, and it works perfectly.
Exactly as I want it to happen. And as you can see they are in the correct order from the numbers.
Please how will you destructure the result you get into [posts, comments]
Please educate me!
That seems to be your problem then. If I was doing
.post, .comment
I don't want them to be seperate. I wouldn't saypost **or** comments
if I wanted only posts or only comments.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
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
Your code is not accurate because you can use the same function you used with querySelectorAll with the returned values of $select. It is querySelectorAll on steroids.
What you would have done is below after first filtering for what you want:
Now, you see the difference ✅
And what exactly is the return value? A
Node
? ANode[]
?null
?How will you infer the return type? Be it for TypeScript, linters or IntelliSense (or similar tools). Whatever the case may be, you'll get what all of us are trying to say once you actually get to programming real things.
What are you saying that I haven't experienced in my 12+ years of programming please?
It seems you don't even understand what is happening here.
When you select a group of elements, you're automatically expecting a node list [ ]. Nothing is hidden about it.
You will certainly get what is expected. Hope you now understand it returns correct values?
Your selector determines what is returned.
Now, it seems you don't get what others complain about. They're worried it shouldn't return Null when nothing is found for a group selection and that it should return an empty array instead of Null.
Even it is not much of a problem when it returns null, it just that it is safer to make sure it returns an empty array when nothing is found for a group selection so that we will just iterate over it without null check and I have already fix it for korasjs@v.0.0.3.
That has nothing to do with your case here.
So
$select(".post")
returns and array instead of a null value?What if I want a single element? The current assumption need for me to check if it's an array and it's empty instead of just checking if it's null. If you think this is a valid solution then the 12 years is too less.
And the fact that you couldn't understand my reference, adds to it.
Why will it return a null when an array of elements is found?
It currently returns Null if a single element is not found.
It also currently returns Null if an array of elements is not found but people are saying it should return an empty array in this case.
What do you think?
No, you won't check for anything if a single element is returned. If a single element is found, it will return a single element. That is not a problem.
You're saying this because you didn't take your time to actually test the tool to be sure of how it works so that you can have factual claims.
It works exactly like you expect. Just try it out and see if it is or not, then you will have factual claims instead of opinions.
I hope you get the point now.
English isn't one of your primary languages it seems. What I meant was, my application might have a single .post element, multiple .post elements or no .post elements at all.
Your tool returns null if there are no elements, single value of there is and array if there is more than one.
The problem is in my case I don't know what I'm getting. Not will anyone who will read or work on my code.
If you still don't get it, don't bother replying. It's okay to stay in the dark, be it you or me.
Nah! Few people in the whole world can match my English skills.
So how does querySelectorAll or querySelector help you in this, your case?
Once you answer this question, I will clearly get your points and probably update the tool for your case, if it doesn't support it already, or I will just tell you how to do it.
Cheers!
Until you know that the underlying method contains
document.querySelectorAll()
as well. Adocument.querySelectorAll()
with added complexity.Oowww… that’s hurt!
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.
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:
$select()
function.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.
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.
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.
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!
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
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.
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:
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!
I like your argument but $select is extensible by composition because you
can build whatever you want on the elements it returns and it is still smaller and with more useful features than all the tools you mentioned above.
Look, the creator of jQuery is a legend to me as he influenced my skills through his writing so no disrespect.
I appreciate the "see a problem, fix a problem" gusto you're showing here; but there are several fundamental architectural issues with the library you're proposing.
** You're inappropriately mixing concerns. A query function should not have built-in capabilities to perform updates. "Select" is a well-known and well-understood term in computer science, and your library takes the knowledge that every single potential user of your library has and turns it into a trap. Select is understood to be and therefore should be a read-only operation, full stop.
**You're building a bespoke domain language where it's not appropriate. None of what you're trying to achieve by adding
add
,remove
, anddelete
into the string is done better than it would be by Javascript code itself; and in trying to reimplement the wheel you've ended up with an ill-defined syntax. How would I use$select
to, say, add anid
offoo]bar
to an element?Adding a bespoke domain language also hinders the ability of tools like TypeScript to syntax check code at compile-time. Which can be worth the headaches that creates if the language you're creating adds value over just using plain old Javascript; but it doesn't here.
I'll also throw in the forward-compatibility problem in that you don't own the CSS selector syntax and so trying to extend it from within is inherently fraught with danger. If some day it evolves to allow
div[remove|id]
as a valid selector (say, by adding the|
character as an operator to attribute selector syntax to say "give me nodes that have either of these attributes"), then you become in conflict with the ecosystem you're trying live on with no clear path out.** You're inconsistent in your interface. Your
$select
method currently returns one of three disjoint return types (null, element, array) based on both the string passed to it and the state of the DOM tree being queried; and that 1) prevents any sort of reasonable strong typing by tools like TypeScript, and 2) requires developers to type-check the result of$select
every time.I understand the desire for a more fluent interface for working with the DOM, but your approach here is fundamentally flawed in concept and is solving problems that frankly don't really exist. Going down your list of "features":
Need an element from a selector by index?
Need to delete elements?
Need to add/remove/modify attributes on elements?
Want a destructured array of NodeLists for several different selectors without having to repeatedly mention document.querySelectorAll?
Want to use normal array methods?
Want to "ship less Javascript?"
Need to "disable superpowers?"
You still don't understand separation of concern yet. I need to write about this because many people assume Separation of Concerns is all about not mixing structures, styles and behaviour.
Every piece of code violates separation of concerns because concerns are relative to problems your solve, the people you're solving it for and the person solving it.
And I will show you examples in this response. Just keep reading.
You're worried everyone already associates "select" with something but you forget we use "$select" in this case to indicate its difference.
And don't forget, $select is a query engine that only processes queries but nothing else. You can't extend its arguments too.
My first question is "have you tried it and do you get all the errors you said in typescript?". If yes, tell me the errors and I will fix them.
I don't understand what you meant by foo]bar. Clarify your intent and will definitely give better solutions that you can't ever get with pure JavaScript.
In understand system design so $select is designed to no use its own operations once a query doesn't match its query. So any change in css queries is catered for.
In case CSS adopts div[remove|id], $select will still work because that is a $select query though we can ship another version of the library to use css alternative. So, that is not a problem because no error would be caused.
Please, don't assume I also didn't worry about everything you're worried about why building the tool. I am also a developer who has similar concerns like you do so I always put in efforts in this regard.
[audio, posts] = $select('#audio, .post');
The only inconsistent thing you can mention is for group selection which should return an empty array when nothing is found so that people won't worry about a case of null and I have adjusted the code here and will be shipped in korasjs@0.0.3
But the rest work as they should.
Your example code are violating my separation of concerns. First, people can easily extend the functions you provided — their arguments and everything about them if it is comfortable to achieve what they want, right? It violate my concern because I don't want to give them that chance. $select should only be extended by composition. You can only extend its returned values.
Your functions hit the DOM every time they're used, meaning I might be forced to extend it. They're also violating another concern.
The alternative your provide means people need to write functions for almost all the attributes we have in html and once you automate them; you're reinventing $select.
You code also violates another concern.
Please, separation of concerns is a relative term. What you're concerned about in a project is different from what you're concerned about in another project. So people should stop assuming is all about separating structures, styles and behaviour.
And before you think I don't understand separation of concerns, think again, it is an adaptation of separation of powers and I have my background in Art.
An article coming on it soon!
I'm not entirely convinced this isn't an elaborate troll.
I think this simplifies how to target DOM using JS and avoids repetition. Using $select() going forward.
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.
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.
That is not what your article is about though. You said you would never use querySelector or querySelectorAll again, and proposed that to others. In a vanilla JS project, not using JSX, then your proposed alternative is not only overkill, but would also be a serious code smell.
Where I work, we have two core functions $ and $$ (not jQuery), that wrap querySelector and querySelectorAll, which take the selector as an argument (with an optional root as the 2nd parameter, defaults to document). So, our code is way shorter than your sample, but only has the overhead of two small core wrapper functions, not a lib that is intended for a whole other purpose (JSX).
If it is a great lib for JSX, then you should have led with that, not the false claim in your article. If you choose this lib over querySelectorAll for every project in future, then you are making a serious mistake, I assure you. So, you are either very misguided, or merely trying to market this lib for some reason.
It seems we are getting onto the same page.
I shared my view after using querySelectorAll and querySelector for many years and compared it with $select but most people here led with their biases without checking $select to know how it works to have a balance view or counter.
I wrote the article based on my experience using querySelectorAll, querySelector and $select() and that means I understand the cases you raised but how do you understand the reasons for my claims without experiencing the solution I provided?
$select, even in isolation, is still better than using querySelectorAll or querySelector in any non-toy projects.
That is my stand.
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.
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.It is okay to act on your biases but it is better to be curious in case something is different.
$select is more than that because it makes it possible to use composition like in React in browsers and servers with only vanilla JavaScript.
Can you do that with querySelectorAll or jQuery? Nah!
Great job on creating something new. I have found it slightly annoying that querySelector and QuerySelectorAll had slightly different returns — not so annoyed I felt the need to create a library for it — but I like the intent.
the DOM destructuring is especially interesting. How would it work if I selected based on attributes (
[data-article]
), elements (article
) or compound selectors (#main h1.article
)?I'm not sure that I like the idea of adding arguments into the function for doing operations. (e.g.
$select('.post[remove|class=hidden]');
That seems like it's a conflation of roles.I would think it'd be more useful to either pass an "operation" argument :
or add a method that could do it:
Those of us that remember the jQuery days probably would prefer the latter.
Putting a remove operation inside of the select argument means that we'd constantly be writing template literals.
I am curious, too, if the operations are commutative. In other words, are these two the same?
This is where I think it might be easier if these were chainable methods:
I'm also curious how I'd select elements by the attribute selector if the square brackets are also used for operations. Would this be a problem?
Regardless of my thoughts, I think it's cool that you recognized a problem you were having in your developer experience and created a solution for it. Good job.
Honestly, you points force me to think more.
I need to look further into the "operation argument" you mentioned.
Thank you!
Honestly I think the best approach is a chainable method, rather than an "operation argument", because then it's extremely clear to any developers what's happening.
But what you could do, internally is have the "operation argument" or a chainable method both reference the same functionality.
Having a generic
.remove()
method where I could pass in an object with any attributes I wanted, and have them all removed at once, has a big appeal:Thank you. I will consider everything to improve the library.
Nice workaround. Congratulations! Destructuration is the most powerful feature.
Thank you!
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.
Your library has an
index.js
file that is 1492 lines long. That is not less JavaScript. With one function:I would already have 75% of its functionality.
Is there a reason you cant do:
It's not that much longer, if the character count is that important.
I could make the argument that your library would introduce more bugs, but eh.
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.You made custom versions of
setAttribute
,filter
,sort
, andjsonStringify
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 leastquerySelector
andquerySelectorAll
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.
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). YourquerySelectorAll
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 theaudio
constant, for instance.It would be better to raise the issues you saw. It might help in making the project better so please don't hold back.
For your information, I am a proud Nigerian.
Now, let me address your opinions.
It is actually mind-blowing if you pay attention and not judge based on your assumptions and experience which is relative to you or try to use the tool before raising any issue.
koras.js makes it possible to use JSX like in React with only vanilla JavaScript without a virtual DOM or tagged templates which is generally considered impossible by every js engineer — isn't that mind-blowing?
And consider I was able to solve the problem using a mathematical formula nth = a + (n - 1)d and ask again "Isn't that mind-blowing?". I digressed.
So, it solves a problem most library solve in hundreds of thousands of lines of code in less than 1450 lines. Don't assume the library only does DOM selections — have you even checked the docs?
Your claim that 1450+ lines of code is for $select is inaccurate. It takes less than 100 lines.
Now, if you try to workaround the issues $select solves, you will end up having bloated code by the time you write 1000 lines of code. If you want to understand my claim practically and emotionally, kindly use the project then you would have a different opinion. Certainly.
I have been using the workaround you raised for years and that is why I could provide a better solution. To really understand my case, please leave your biases aside and use the thing.
Also, $select comes with a lot of operations you will need to repeat when you use querySelectorAll but with $select, you only need a line of code in many cases.
You said you didn't like the name because it seems to do many things but that is not accurate.
$select is a query processor and all it does is process queries. It does a thing. The queries you pass to it are the ones that delete, filter and co. and you need to specify them.
You said I made my custom jsonStringify(). Do you know why? It is because JSON.stringify() has some issues so don't let me go into more details about that. That is it.
Thanks!
I don't get it.
How is
document.querySelector()
anddocument.querySelectorAll()
sticking to the distant past while missing many juicy features in Javascript?The library you suggest just in turn uses
document.querySelector()
anddocument.querySelectorAll()
This seems like something cool to use... but completely disposable. At least for the purpose that the author of the article proposed.
It will never, ever, be better to use a library for something that you solve, natively, with just a few, or one, lines. At the very least, you will be adding and becoming hostage to something external, which could cease to exist overnight.
So, the idea is cool, but saying that this replaces the native method, or simplifies it just because it 'writes less', that's wrong, just the main code of the library is 1500 lines. Just because I don't see it, does that mean it's smaller?
Concern is solid but truth the code for $select is about 100 lines of code and $render uses the rest because it makes it possible to use JSX in browsers and servers without a virtual DOM or tagged templates.
So, it is not 1450+ code.
I combined $select and $render because they work best together for better composition.
And you did a great job, actually, better than I would have done.
However, I think you were wrong to "sell" the idea as just a replacement for query.selector, your tool does more than that.
But in a one-for-one context, using the native tool is more advantageous, at least for the specific case of your article.
Maybe if you try to put it another way, acceptance would be better.
I feel like creating a library to replace these functions is over kill.
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.
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.
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 withquerySelector/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.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 thatquerySelectorAll
does.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.
In the jQuery/Prototype heyday we were used to writing
$('.posts')
and do all sorts of things with the result. I think $select commits the same mistake as the jQuery function.const header = $select('#header')
versusconst header = document.querySelector('#header')
With the $select function you are missing the information that the code wants a single element.
You can make a static analysis rule to check that an id selector has to use the querySelector method, or even better use the getElementById method. Making the intention of the code as specific as possible, improves the readability.
That is not possible with the $select function, because it is too generic.
While
$select('.post[delete|i=2]');
might look readable, it is not clear what the result is.If I read the code correct, it returns the removed elements. With the name select I would expect the return to be the elements without the deleted element(s). I'm not saying the return of the function is wrong, I can see a case for both returns. It just makes the result opaque.
$delete('.post', 'i=2')
causes less confusion, in my opinion. But then is it that hard to writedocument.querySelector('.post:nth-child(2)').remove()
?With the element and attribute actions the order of the actions is important.
$select('.post[delete|i=2][add|class=hidden]');
and$select('.post[add|class=hidden][delete|i=2]');
While you get the same return, the second example does a lot more manipulations.
Because the code that does the actions is hidden, it is harder to identify if it going to be a problem or not.
I also think the action names are too generic, like delete and remove. Because they are synonyms people are going to confuse those. Or even wonder why there are two actions with a similar name.
I looked at the code, and I see you put a lot of effort in it. The pursuit to write less code is good.
I think that single focus brought the code to a place where the negatives outweigh the positives.
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.
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.
const [posts, comments] = [$all(".post"), $all(".comment")]
What I am missing here is performance analysis (including increased memory pressure from the additional allocations from temp arrays and string splits).
If I am making a compromise (which this is), I want to know what I am trading (in addition to the added complexity of "stringly" typed language, additional external dependency, learning curve, ...).
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:
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.
I don't want to be too harsh since clearly you've gotten plenty of criticism (though most of it seems reasonable to me). It's good to build something and put it out there. That said, I personally wouldn't use this because I don't like the idea of putting such power into potentially long and complicated strings. Seems like the kind of thing that would eventually lead to string manipulation being needed, which I'd rather avoid if possible.
Why do you assume string manipulation would be needed?
It is obvious you opinion is based on your biases other than curiosity.
If you had checked the tools, you would have had a balance view.
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
I think you omitted one important line when writing your library and this post:
import { humility } from "./basic-human-traits";
Oh, please let me learn why you said that. And if it requires direct messages, I am comfortable either ways.
Thank you.
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
Yeah, it is useless when you start using $select.
What if I wanted to chain selectors
Why would you do that when you can destructure them and apply the operations you want in the query?
You chain selectors because you can only work on a element at a time.
With $select, you can select every elements you want at once and still apply some operations to them.
For example,
const [posts, postImgs] = $select('.post[add|class=bounce], .post>img[add|style= 1px solid blue]');
The experience of using select is much better.
Smells dangerously like code golfing.
Over the last twenty years in front-end I have accumulated sufficient trauma inflicted by those who think writing code is all a software engineer does.
Over the past 13 years, I have learned many developers assume there is monopoly of experience and understanding.
Nonsense!
Congrat you ve just reinvented Jquery
It is more than jQuery. It gives JSX without using a virtual DOM or tagged templates.
Yeah! Honestly, my programming skill was influenced by John Resig because I learned from his book years ago.
Is there a library called jQuery?
This is not jQuery in operations.
Nice ad disguised as critique on vanilla JS.
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
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.