ƒu.js - The Functional DOM traversing library.
tsenart.github.com
tsenart.github.com
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.
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.
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.
Honesty without a push is just a statement and nothing more.
> http://help.dottoro.com/ljlumkqh.php
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:
E.g.:
try {
eval('el.' + argv[1]);
return el;
} catch(e) {
return null
};
Why in the world would you do this? JavaScript has property access via bracket syntax for a reason: return el[argv[1]] || null;
Give this a read: https://developer.mozilla.org/en/a_re-introduction_to_javasc...Consider that the "black" portion of that argument actually comes from user input and that you were passed instead:
black"); alert('This framework is awesome!
Try eval'ing that.
At the very least you could link to the previous discussion, no?
---
ƒ('selector1').ƒ('selector2').ƒ('selector3');
vs.
$('selector1 selector2 selector3');
---
ƒ('body').style.background = '#f4f6f8';
vs.
$('body')[0].style.background = '#f4f6f8';
---
for (var i=0; i < 50; i++) { ƒ('ul').appendChild(ƒ().createElement('li')); }
vs.
$.each($('ul'), function(index, ul) { for(var i=0; i < 50; i++) { ul.appendChild(document.createElement('li')); } });
---
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?
How? No, seriously, how is
ƒ('body').style.background = '#f4f6f8';
much nicer than $('body').css('background', '#f4f6f8');
? fu().body.fu('ul').appendChild(ƒ().createElement('li'));
than $('body ul').append($('<li>'));
? document.body.ƒ('ul li:last-child').innerText = "I'M THE NEW GUY!";
than $(document.body).find('ul li:last-child').text("I'M THE OLD GUY!");
? for (var i=0; i < 50; i++) {
ƒ('ul').appendChild(ƒ().createElement('li'));
}
than for (var i=0; i<50; ++i) {
$('ul').append($('<li>'));
}
? ƒ('ul li:nth-child(2n)', 'style.background = "black"')
than $('ul li:nth-child(2n)').css('background', 'black')
? $('body ul').append($('<li>'));
can become: $('body ul').append('<li>');
and: $(document.body).find('ul li:last-child').text("I'M THE OLD GUY!");
can become: $("body").find('ul li:last-child').text("I'M THE OLD GUY!");
(We optimize for body explicitly in our selector code.) Although that last example selector is rather weird, it's equivalent to: $("body ul li:last-child")
or even just: $("ul li:last-child")
(When is a ul ever going to be outside of a body element?) 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.
> (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~~
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
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"
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).
e.g. Sizzle('div:first')