Is jQuery worth a second look?

[Bruno Desthuilliers]

PaulHan a écrit :
(snip)

If javascript really is going to
become the 'C' of the internet, JQuery could very easily become it's
STL.

Actually, the STL is for C++, which is a quite different language !-)

 

[David Mark]

Answering your original question, I think JQuery is the best thing
since sliced bread for somebody who wants to get up to speed quickly
on this whole "Web 2.0" paradigm.

You are badly misinformed about "Web 2.0" and using jQuery is not
going to help.

The browser wars have restarted, and we have HTML 5, CSS 3.1?
Ecmascript 3.1/Harmony, and DOM 3 about to be unleashed on us. With
Google Chrome and the need to support at least the last two versions
of each major browser, it'll be impossible to keep up with it all,
because even with the best will in the world on the part of the
browser vendors, things are going to get broken, or not fully
implemented at the same time.

And those jQuery morons rely on browser sniffing. See the problem? I
can't even remember the last time a new browser broke one of my
applications (as I ignore the name/version of the browser.)

A library is the only way to abstract this out, and with all the other
things a developer has to handle for your average Web 2 page/app,
building and maintaining your own is only for the serious masochist,

More echoes of blithering past.

IMO.
A year ago, when I was evaluating what library to use, I went for
JQuery as soon as I saw it, because by every metric that I was

You didn't know what you were doing then (or now apparently.)

interested in, it came out ahead of the alternatives. I wasn't aware
of many of the things raised on this forum and elsewhere, but even if
I was, I would still have gone for it, because it just works, stays

It does NOT "just work." Are you out of your mind? Have you read the
miserable code?!

out of the way, and makes my own coding both easier, and smaller.

You aren't really coding though are you? You are relying on code
written by other people. Unfortunately for you, these other people
have been proven to be completely incapable.

In a sense, it's a pity this conversation didn't wait until 1.3 came
out, because I believe there will be quite a lot of changes/additions
to the library. There's the 'Sizzle' selector engine, which is going
to be faster than the current one and it will also be using a
different form of feature / browser detection, which I believe will
make it the only library not using browser detection.

LOL. Where have you been? If he does do that, I bet I know where the
code came from. Of course, as noted by Henry, the whole thing is a
botched design and can't be salvaged. It is like putting perfume on a
dead rat.

It would be very interesting to see what the opinions and insights of
this forum are to those changes. If javascript really is going to
become the 'C' of the internet, JQuery could very easily become it's
STL.

No, there is not a competent JavaScript programmer on earth who would
use jQuery. Not one. In fact, the use of jQuery is a direct
indicator of incompetence.

 

[David Mark]

Do some of the regulars here need to re-think their (sometimes
strident) opposition to libraries?  Both Microsoft and Nokia have
announced support for jQuery.

Microsoft has always been clueless when it comes to the Web
(see .NET.) Who knows what Nokia is thinking? I don't think they
are.

It seems to have gained quite a bit of momentum, can it be considered

You mean lots of twits are using it? The same ones that post faux
XHTML pages all over the public Internet? How ironic that jQuery is
incompatible with XHTML. It seems the stupider the idea, the faster
Web developers rush to embrace it.

a reasonable choice for those who want to use a full-featured, well
supported library?

Full-featured? What does that mean in the context of a Web app? Well
supported? By whom? Have you read *any* of the authors' posts on
browser scripting? You are standing on the shoulders of midgets.

Then there is the browser sniffing (unthinkable even ten years ago),
the botched design (discussed ad nauseum here), the ridiculous and
completely inefficient patterns it promotes, and last but not least,
the author was once presented with a line of code from his own library
that went something like:

if (typeof someStupidOverloadedArgument == 'array') {
[Orphaned code in all known ECMAScript implementations]
}

Can you spot the egregious error? He was given more than one shot at
that and came up with blanks. This is the JavaScript expert/
evangelist/ninja/whatever that you are going to turn to for "full-
featured" browser scripting code?

And then there was the sniff for Safari when an event target came up a
text node. (!) I *personally* pressed their forum to fix that one,
just to see how quickly this herd could maneuver. I got a few
ridiculous and petulant responses and last I heard, that line of code
was still in there (a year later!)

Think of this group of open source weekend warriors as a very large,
very stupid (and very endangered) dinosaur. The head is way too far
from the tail (and ill-equipped to interpret its messages anyway.)
The fact that lots of insects are landing on it isn't notable for
anything but irritation (I really hate browsing the Web these days.)

 

[dhtml]

if (typeof someStupidOverloadedArgument == 'array') {
[Orphaned code in all known ECMAScript implementations]
}

That was removed several months ago.

The current discussion is along the lines of Object.prototype.toString,
which (if not replaced) is designed to return the string "[object " +
[[Class]] of this object.

Faux-overloading is less than ideal, and in javascript, even less than
that because typeof is weak and because instanceof/ isPrototypeOf
doesn't work across frames.

A recent jQuery proposal was to use Object.prototype.toString.apply(o).
They'll may end up realizing that call is faster in Firefox (well now
they do ).

var o = [];
Object.prototype.toString.call(o) == '[object Array]';

Which is guaranteed to work, unless someone goes and replaces
Object.prototype.toString as in:
http://groups.google.com/group/comp.lang.javascript/msg/7c7940e84ab9535b?dmode=source


(Yikes!)

I don't know what the for in link was for. Even if the value is changed,
Object.prototype.toString will still have the DontEnum attribute.

This will work for Function and RegExp objects, too:

Object.prototype.toString.call(/a/);
Object.prototype.toString.call(function(){});


Garrett

 

[David Mark]

On Sep 28, 6:24 pm, RobG <[email protected]> wrote:

if (typeof someStupidOverloadedArgument == 'array') {
    [Orphaned code in all known ECMAScript implementations]
}

That was removed several months ago.

Several months too late IMO. I wonder how long it would have lingered
in the bowels of jQuery if the solution wasn't literally force-fed to
them. All those eyes, but seemingly no brains or ability.

The example was to illustrate the relative ignorance of "Mr. jQuery"
and there are plenty more out there. Just read his blog entries (or
books if you are one to throw away money.)

The current discussion is along the lines of Object.prototype.toString,
which (if not replaced) is designed to return the string "[object " +
[[Class]] of this object.

Faux-overloading is less than ideal, and in javascript, even less than
that because typeof is weak and because instanceof/ isPrototypeOf
doesn't work across frames.

Right, it all goes to show what an inept design they are dealing
with. Everybody makes mistakes, some people learn from them, others
spread them all over the Internet.

A recent jQuery proposal was to use Object.prototype.toString.apply(o).

They'll may end up realizing that call is faster in Firefox (well now
they do ).

I doubt they know it now. They discuss browser scripting issues at
the bottom of Web pages.

var o = [];
Object.prototype.toString.call(o) == '[object Array]';

Of course, such issues should be eliminated during design.

Which is guaranteed to work, unless someone goes and replaces
Object.prototype.toString as in:http://groups.google.com/group/comp.lang.javascript/msg/7c7940e84ab95...

(Yikes!)

Ugh. You never write wrong answers on the blackboard.

Along the same lines, I recently saw a script on a major site that
replaced String.prototype.replace with some made-up nonsense with
completely different specs.

I don't know what the for in link was for. Even if the value is changed,

That's where he explains one of the reasons why it is a crazy thing to
do. Bad form to post a wrong answer and a link to the explanation of
why it is wrong.

Object.prototype.toString will still have the DontEnum attribute.

Okay, perhaps the link to the for-in intrigue article is less than
helpful here. I can't say for sure as I haven't read it in ages. In
general, it is a good article to read.

Plenty of other reasons not to do it though. The simplest is that it
could create difficult problems in other scripts.