I don't understand this argument at all. So this guy is proposing that
we change all the jQuery methods to:
$Array([array of elems])
$Selector("str")
$HTML("html")
$Element(DOMElement)
and:
.appendElement(DOMElement)
.appendHTML("html")
.appendArray([array of elems])
what on earth does that gain you? What's the purpose of using a
language that can overload arguments and not actually using that
feature? What's the advantage of increasing the size of your API
4-fold?
Incredibly weak argument, obviously someone who's never used the library.
> Some method names make no
> immediate sense, like .one or .eq, and you can't immediately tell if a
> method acts on the first element in the collection or all of them.
These arguments are slightly more valid. Although .eq() is going away
in 1.2. I really don't know what to say, in this case it was simply a
design decision. We could've had:
.val() (return nothing, do nothing useful)
.val("val") (set value)
.getVal() (get value)
.getVal("val") (return nothing, do nothing useful)
But why have a state of a method perform nothing useful at all? Why
not overload it to actually do something? Why double the size of the
effective API with half-useful functions?
--John
On 8/16/07, Mitch <[EMAIL PROTECTED]> wrote:
>
> What do you guys think of this critique of jQuery I found on Simon
> Willison's site (which is good reading).
>
> http://simonwillison.net/2007/Aug/15/jquery/
>
> <quote>
> jQuery is definitely a popular utility function library, but the sheer
> amount of dual/triple/quadruple special-case uses for both function
> calls and method names is an instant turnoff for me.
>
> The jQuery object itself can perform a selector query, embed a DOM
> element, create a DOM element from HTML and assign a DOMContentReady
> event handler - and probably more. Event handling is separated into
> separate methods for each event type. Some method names make no
> immediate sense, like .one or .eq, and you can't immediately tell if a
> method acts on the first element in the collection or all of them.
>
> I can't recommend jQuery to the developers I am mentoring because it
> is in itself a completely separate abstraction, and a muddy one at
> that. They will end up having to learn jQuery instead of having to
> learn DOM, CSS and JS, and when being considered as a direct
> replacement for those it fails both due to complexity and
> inconsistency."
>
> </quote>
>
> Mitch
>
>
