Why would you use this over normal querySelector{All}? Also, why do you define a window.typeOf global? It completely defeats the purpose of using a clousure.
You also seem to be checking `typeof value.length == 'number' && typeof value.splice != 'undefined' && !value.propertyIsEnumerable('length')` to determine if something is an Array. First of all, the recommended practice is to check Object.prototype.toString.call(value) === "[object Array]", but since you're going to rely on latest browsers supporting querySelector{All}, you might as well use Array.isArray.
I'm sorry for being so harsh, but this is the most worthless library I have ever seen. You're adding an extremely thin and pointless layer of abstraction to querySelectorAll and polluting the global namespace with four globals, three of which are completely identitcal, and two of which take too much effort to type. Not to mention your use of worst practices (such as using eval(), only loose comparisons, wrapping all of your code in try..catch statements instead of just not doing things that will throw errors, etc.) and your prototypical pollution in Array, Document, and Element. For example, you define Array.prototype.flatten for internal use. You shouldn't pollute global prototypes for something that you can do privately.
I think you bring up valid points, but you should work on delivery. Your post is very offensive to read, even from someone who has no stake in this library whatsoever - even though I think you're right.
You've also got a lot of typos.
So, try to be helpful and encouraging instead of damning and dismissive? I'd appreciate that, and be more open to what you're saying.
His delivery is exactly what anybody is bound to get on the internet, and there's seriously nothing wrong with it. If you have an issue with brutal criticism like that, you should re-evaluate even spending time on this site.
This is, quite simply, the most _useless_ and badly written 'library' I've seen in some time. I applaud the author for pushing his work out there, but this is the part where you take criticism and run with it, fix it. Listen to Sephr, he's spot on.
If my criticism is too forgiving, he may just brush it off and not take any action regarding it. I feel that he needed more brutal criticism so he might take some time to learn the "good" way to write JavaScript for any of his future projects.
Ouch. There is value in being able to handle extremely harsh criticism. There is also value in being able to say things nicely, with the knowledge that your words will be more easily heard by the person on the other end, and put to use rather than dismissed out of anger.
This may be irrelevant to original comment but does querySelector work in all modern browsers? My understanding was that it doesn't and so there is need for CSS selector engines like jQuery's sizzle.
The page implies that there is limitations to the IE8 implementation, and that it's only available in relatively recent browsers. In addition, I believe that sizzle implements a set of selectors larger than most or all browsers support natively, although this I am less sure of; the Sizzle documentation certainly implies it strongly:
Even tough he is being harsh I guess he is right. I am not a ninja Javascript programmer and this is my first library. Thanks for the tips. I have a lot to learn. Also, this is a toy project made in one night that I had no internet access. If you don't like it, don't use it. I'm not selling it as the ultimate solution to all problems. It's my personal play and I learned with it and had no intentions of being so serious. If you noticed, I have the following on the README.md:
"I'm sleepy. Don't know if this is too useful yet... Playing with Unicorns.(Unicodes)"
There are alot of bad practices being used in this code. It gives the impression that you've (ab)used JavaScript for a long time, but haven't actually bothered to read the 101 introduction to the language.
A better way to do that would be to split() it first on '=' then, split() the left side on '.' and iterate the results. You don't want to evaluate just anything anyone puts in that second argument.
If you want to eval anything anyone passes you with no consideration for what it could be, then I have to agree with OP that you must not be aware of the pitfalls of using eval.
Consider that the "black" portion of that argument actually comes from user input and that you were passed instead:
Disclosure: I think I got misunderstood. This is not a serious library meant for multi-browser support or a general purpose library like jQuery (which I use daily). It's a toy project born out of interest, will to learn and the simple fact that in another project I have, Sight(https://github.com/tsenart/sight), I didn't use any external libraries (except Underscore.js). That's how I really started to learn Javascript. I missed the ability to directly iterate through the results of document.querySelectorAll() so I just had fun playing with a solution and ƒu.js came out. I'm not praising it as the best library in the world. And it can even have no advantages over the others. It's just my toy project with which I learned a lot (and even more with brutal criticism) and published for the others to see.
Not selling anything here. (The headline of the page is mere satyre)
Am I missing something here or do I really have to type the weird curly-F every time I want to call this? Having charmap open in my taskbar is not my idea of being productive. Plus, from my cursory glance this looks pretty similar, if not almost identical, to jQuery...
I'm not even a jQuery user but I don't see a lot of difference in your approach versus jQuery's here. I already only use lightweight libraries like jQuery or Ext.Core for situations which call for only minor Javascript (read: not an RIA).
In what situations do you imagine your framework is more useful?
document.body.ƒ('ul li:last-child').innerText = "I'M THE NEW GUY!";
That code won't work in standards-compliant browsers. You should either use .textContent = "..." or .appendChild(document.createTextNode("...")) or .firstChild.wholeText = "..." if there's already a text node child.
The real issue though is that unlike jQuery, ƒu.js won't work in popular versions of IE.
Well apart from the first one (clearly my mistake) I was trying to translate the original semantics as closely as possible. Hence the repeated (if not very useful) `body` anchors.
> (When is a ul ever going to be outside of a body element?)
Document fragments? XML documents? Not sure you can use that style of jQuery calls on those, but~~
well for a start, Fu.js is using straight forward assignment statements with the = sign, whereas in jquery you're passing two arguments into a function without being able to see what they're for or what order they should be in.
some of the fu.js lines are a bit unwieldy but at least it's obvious to me what they do - i found jQuery code pretty bewildering until i delved into it
> whereas in jquery you're passing two arguments into a function without being able to see what they're for or what order they should be in.
Unless, of course, you've spent roughly 5mn reading upon how jQuery's getting and setting works. Then you know the first argument is a key and the second one is a value to set.
I can see you've also quickly moved the goalposts, from "fu.js's syntax is much nicer" (emphasis yours) to "I claim to undetstand what fu.js does without having read its documentation"
Well in the original examples I responded to, I thought the syntax was considerably nicer, that's what I was commenting on. In the different examples (shifting goalposts...) someone responded to me with, the benefit was less pronounced. In general, jQuery has absolutely horrible syntax (IMO), so I can understand someone building a library to make a few small improvements like normal assignment statements.
I don't think "nothing like jQuery" is really correct here; its API is very similar to jQuery. In fact, it behaves a lot like a very small subset of jQuery, as a neighbouring post to this one points out.
I can imagine it's handy if one wants something like the jQuery API but doesn't need support for all of the CSS selector features, or for older browsers, and wants to save a few bytes on downloads, given that it's much smaller (the uncompressed jQuery source is something like 60 times the size of this library, although in its defence that includes inline documentation).
Umm how the hell am I suppose to type "ƒ" every time? I know I can "map" it to some other character, but that kinda defeats the purpose, no? Other than that it looks nifty, but since I'm already using jQuery in all of my projects I don't think I have much use for it.
It's a Mac thing. Alt-f prints ƒ on Mac. On any other OS it's a pain in the ass. Granted, you can use fu but I think it would have been wiser to promote the usage of fu instead of ƒ.
It's not really meant for general purpose. Just for projects where you want raw javascript performance and need a little help for traversing and manipulation of DOM elements as arrays. Like my Chrome extension: Sight: https://github.com/tsenart/sight.
You also seem to be checking `typeof value.length == 'number' && typeof value.splice != 'undefined' && !value.propertyIsEnumerable('length')` to determine if something is an Array. First of all, the recommended practice is to check Object.prototype.toString.call(value) === "[object Array]", but since you're going to rely on latest browsers supporting querySelector{All}, you might as well use Array.isArray.
I'm sorry for being so harsh, but this is the most worthless library I have ever seen. You're adding an extremely thin and pointless layer of abstraction to querySelectorAll and polluting the global namespace with four globals, three of which are completely identitcal, and two of which take too much effort to type. Not to mention your use of worst practices (such as using eval(), only loose comparisons, wrapping all of your code in try..catch statements instead of just not doing things that will throw errors, etc.) and your prototypical pollution in Array, Document, and Element. For example, you define Array.prototype.flatten for internal use. You shouldn't pollute global prototypes for something that you can do privately.