Is jQuery worth a second look?

[dhtml]

Re: Is jQuery worth a second look?

kangax wrote:

On Sep 30, 12:13 am, dhtml <dhtmlkitc...@g mail.comwrote:

>Conrad Lender wrote:

>>On 2008-09-29 08:09, dhtml wrote:
>>>Absolutely worth taking a look at objectively. The code is taken quite
>>>seriously by the industry, so it's a good idea to understand it and to
>>>do that, it should be objectively reviewed.
>>>>>>It seems to have gained quite a bit of momentum, can it be considered
>>>>>>a reasonable choice for those who want to use a full-featured, well
>>>>>>support ed library?

>isFunction - still uses function decompilation. Kangax posted on
>es-discuss that that was changed but I still see the isFunction in the
>latest 1.2.6.
>>

>
Garrett,
their trunk is using `instanceof` [1]. Wrapping a single operator into
a method seems like an overkill, but... whatever works for them. We,
in prototype.js, are more inclined to get rid of is* methods at all.
Having such "helpers" seems to solve very few (if any) problems.
>

Keeping isFunction is understandable for backwards compatibility.
However, they don't need to keep using isFunction internally for that.

Of course it won't work across frames.

--
kangax

[Henry]

Re: Is jQuery worth a second look?

On Sep 30, 5:06 pm, Oltmans wrote:

On Sep 30, 6:38 pm, "Thomas 'PointedEars' Lahn" wrote:

>>kangax wrote:

>>dhtml wrote:
>>>isFunction - still uses function decompilation. Kangax posted on
>>>es-discuss that that was changed but I still see the isFunction in the
>>>latest 1.2.6.

>

>>Garrett,
>>their trunk is using `instanceof` [1].

>

>Irrelevant, except that it shows their cluelessness.

>
Why using "instanceof " considered to be not so good? Can you
please explain it to me with a few examples? That will be
highly appreciated.

The - instanceof - operator makes assertions about the runtime
relationships between the objects on the prototype chain of one object
and that object that is the value of the - prototype - property of a
(single) function object. Because it is possible, at any time, to
create objects with virtually any other object on their prototype
chain, and to assign to the - prototype - properties of most functions
(though not the built-in constructors) that relationship is only as
meaningful as to can be know to be. It is in the nature of library
code that it has no control over, or knowledge about, the code that
employs it or sits around it, and so no guarantee of the usefulness/
applicability of the relationship being tested.

[Henry]

Re: Is jQuery worth a second look?

On Sep 30, 5:45 pm, dhtml <dhtmlkitc...@g mail.comwrote:

kangax wrote:

>Garrett,
>their trunk is using `instanceof` [1]. Wrapping a single
>operator into a method seems like an overkill, but... whatever
>works for them. We, in prototype.js, are more inclined to get
>rid of is* methods at all. Having such "helpers" seems to solve
>very few (if any) problems.

>
Keeping isFunction is understandable for backwards
compatibility. However, they don't need to keep using
isFunction internally for that.

Because of the ill-advised use of emulated method overloading in
JQuery (which is so fundamental to the design at the lowest level that
it is a mistake that can never be fixed) it will remain necessary to
make the sort of type distinctions that the - isFunction - function
was intended for. Even if some alternative is used internally the
faults and shortcomings of existing/previous - isFunction - efforts
will still live on under the hood.

Of course it won't work across frames.

The rest of JQuery does not work across frames (just look at all of
those unqualified - document - references) so - isFunction - not
working across frames is not actually making things worse than they
would be otherwise.

[Oltmans]

Re: Is jQuery worth a second look?

On Sep 30, 9:44 pm, dhtml <dhtmlkitc...@g mail.comwrote:

Oltmans wrote:

On Sep 30, 6:38 pm, "Thomas 'PointedEars' Lahn" <PointedE...@we b.de>
wrote:

kangax wrote:
>dhtml wrote:
>>isFunction - still uses function decompilation. Kangax posted on
>>es-discuss that that was changed but I still see the isFunction in the
>>latest 1.2.6.
>Garrett,
>their trunk is using `instanceof` [1].
Irrelevant, except that it shows their cluelessness.

>

Why using "instanceof " considered to be not so good? Can you please
explain it to me with a few examples? That will be highly appreciated.

>
Instanceof won't work like you want it to across frames. This is because
self.Function != frames[0].Function.
>
frames[0].fun instanceof Function will return false across frames.
Two documents example:
document1.html
myframe.html:
>
document1.html:
<body>
<iframe src="myframe.ht ml"></iframe>
>
<script>
onload = function() {
var f = frames[0].fun;
document.write(['<pre>',f instanceof Function, f].join('\n'));
document.close( );};
>
</script>
>
</body>
>
myframe.html:
<script>
function fun() {}
</script>
>
Result:
false
function fun() {
>
}
>
So we can see that instanceof won't work across frames like you'd want
it to, and the isFunction uses instance of.
>
Garrett

Thank you for the examples.

[RobG]

Re: Is jQuery worth a second look?

On Oct 1, 1:04 am, Matt Kruse <m...@thekrusef amily.comwrote:

On Sep 28, 5:24 pm, RobG <rg...@iinet.ne t.auwrote:
>

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.

>
I think it is warranted, and I thought so a year ago :)
>
I realized quite some time ago that jQuery was gaining momentum and
would soon be one of the de-facto standards for Javascript
development. It's not perfect. It has some design flaws. Its internals
could use some cleaning up. But what general-purpose technology
doesn't?
>
HTML is seriously bastardized and has been abused for over a decade.
CSS is far from perfect and has some seriously questionable design
decisions. Javascript as a language itself has some drawbacks, quirks,
and missing features that would make life better. So here comes
jQuery, which is not perfect by any means, but is ridiculously useful
and has made interactive javascript more accessible to the mainstream.

The primary reason I balk at using jQuery or similar libraries is that
a great deal of the basic, cross-browser functionality required for a
specific job can be accomplished in very much less code. Other really
helpful bits like 'each' are pretty simple to do and seem prime
candidates to be added in the next version of ECMAScript. So much of
what libraries do is easily replaced using standard javascript that
anyone should be able to maintain, I don't need a jQuery (or Dojo or
Prototype.js) specialist.

I'm not a fan of highly active user interfaces - I really dislike
things that fade in and out or slide up and down or popup tool tips.
Therefore many of the animation and special effects are of no use to
me.

I'm in favor of it. And I'm in favor of improving it, because it is
quickly becoming a tool that is used by many people.
>
Some important points for me:
>
1) It works. I know it has some internal problems like browser
sniffing and code that isn't as accurate as it should be. But in every
case where I have decided to use it, it has worked and worked well in
most cases. Argue all you want about it being 1px off or slow or how
it _could_ work in browser X if it just didn't browser sniff... but in
reality, in many cases, it works and works well.

I would feel more comfortable with that if there was evidence that
such issues were being actively addressed, but there seems to be more
browser sniffing with each release (there are about 30 in v1.2.6).
Guess Nokia are hoping that the special stuff for "webkit" aka Safari
will suit its browser (there are about 10 sniffs specific to Safari,
some for specific version numbers).

2) It's supported. The discussion lists are very active and there is a
huge community around it. It's under constant development. Momentum is
in its favor. That's a good thing.

The volume of discussion on lists isn't much of an indication,
typically there is a large bubble at the beginning that tapers off.
Nor does it indicate the quality of response (in fact it can show the
reverse). A good percentage of posts don't get answered at all.

A better indication is the frequency of updates and bug fixes and the
availability of well-written books, articles and tutorials. I can't
comment on that, but the documentation on the jQuery web site leaves a
lot to be desired.

3) It encourages unobtrusive scripting. Sometimes too much, IMO. But
by its nature it encourages people to put classes on their HTML tags
and add the behavior after the page is ready. It doesn't encourage all
the best practices, but it's a step in the right direction.

Putting aside my dislike of the term "unobtrusiv e scripting", I don't
think it necessarily encourages it more than say putting scripts at
the bottom of the page.

Once you start attaching behaviour based on some form of general
selector (even something as simple as a home-grown
getElementsByCl assname function), it’s hard to go back to in-line or
specific functions to do the job. I would argue that a lot of such
functionality can be similarly processed at the server and a simple in-
line listener added, but that’s for another discussion that would
likely end in “horses for courses”.

4) Plugins are questionable. The base jQuery library has a lot of
fundamentals, but if you want "controls" then you need to venture into
the plugin territory. And sometimes this is bad news. The quality of
the plugins is, generally, much lower than jQuery itself, IMO. Be
careful what you use. In some cases, I have been writing my own
because the ones that exist aren't good enough.

This is supposed to be a "for" list. :-)

I think plugins are the major benefit for many users (i.e. web page
authors), anyone who is unconcerned about the issues of using jQuery
is likely not fussed by the issues of using poorly written plugins
(that is not to say all plugins are poorly written, just that users
don’t really care, just so long as “it works” in maybe 4 different
browsers where IE is two of them).

I don't think jQuery (or any general-purpose lib) is the right tool
for everyone. If you have the skill, time, and money to build all your
components from scratch, then go for it. For everyone else, I think
jQuery is the best possible route to go right now and the foreseeable
future.

If it replaces the massive bloat that comes with .NET by default, that
has to be a tick in its favour.


--
Rob

[Matt Kruse]

Re: Is jQuery worth a second look?

On Sep 30, 10:25 pm, RobG <rg...@iinet.ne t.auwrote:

The primary reason I balk at using jQuery or similar libraries is that
a great deal of the basic, cross-browser functionality required for a
specific job can be accomplished in very much less code.

True, if you know how to write it. Many people don't.
And I've reached the point on projects where I'm including jQuery
anyway, as a standard piece of a webapp, so why not use its built-in
reusable functions? At least then any other person with jQuery
experience can come in and know what code is doing without learning a
custom-built internal API.

I'm not a fan of highly active user interfaces - I really dislike
things that fade in and out or slide up and down or popup tool tips.
Therefore many of the animation and special effects are of no use to
me.

I dislike those things on most internet pages, but on internal webapps
I find that users really like that stuff. It makes the webapp look
more like a desktop app.

1) It works. I know it has some internal problems like browser
sniffing and code that isn't as accurate as it should be. But in every
case where I have decided to use it, it has worked and worked well in
most cases. Argue all you want about it being 1px off or slow or how
it _could_ work in browser X if it just didn't browser sniff... but in
reality, in many cases, it works and works well.

I would feel more comfortable with that if there was evidence that
such issues were being actively addressed, but there seems to be more
browser sniffing with each release (there are about 30 in v1.2.6).

I agree, and I'm not sure why this is the case. The main developers of
jQuery still seem a bit naive and inexperienced to me. Their approach
often seems to be "as long as it works, don't question it!". There is
room for improvement in some of the fundamental code (changes which
seem pretty obvious to make) yet they are ignored. Not sure why. I
guess they aren't trying to impress the hard-core js developers,
because that's not their audience (now).

3) It encourages unobtrusive scripting. Sometimes too much, IMO. But
by its nature it encourages people to put classes on their HTML tags
and add the behavior after the page is ready. It doesn't encourage all
the best practices, but it's a step in the right direction.

Putting aside my dislike of the term "unobtrusiv e scripting", I don't
think it necessarily encourages it more than say putting scripts at
the bottom of the page.

I think many plugins and jQuery examples illustrate the idea of
attaching behavior to objects after page load, using selectors. That
is a new concept to many developers, and something good to learn. It's
certainly not unique to jQuery.
I personally feel like jQuery goes a bit too far in this regard
sometimes, and I do actually put a lot of calls inline in html to
speed up pages.

4) Plugins are questionable.

This is supposed to be a "for" list. :-)

Not it wasn't, it was just a list of the most important things that
need to be pointed out about jQuery, IMO :)

If it replaces the massive bloat that comes with .NET by default, that
has to be a tick in its favour.

Most certainly. I've not seen much worse on the web than the nastiness
created by .NET.

Matt Kruse

[PaulHan]

Re: Is jQuery worth a second look?

On Oct 1, 4:25 am, RobG <rg...@iinet.ne t.auwrote:

On Oct 1, 1:04 am, Matt Kruse <m...@thekrusef amily.comwrote:
>
>
>

On Sep 28, 5:24 pm, RobG <rg...@iinet.ne t.auwrote:

>

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.

>

I think it is warranted, and I thought so a year ago :)

>

I realized quite some time ago that jQuery was gaining momentum and
would soon be one of the de-facto standards for Javascript
development. It's not perfect. It has some design flaws. Its internals
could use some cleaning up. But what general-purpose technology
doesn't?

>

HTML is seriously bastardized and has been abused for over a decade.
CSS is far from perfect and has some seriously questionable design
decisions. Javascript as a language itself has some drawbacks, quirks,
and missing features that would make life better. So here comes
jQuery, which is not perfect by any means, but is ridiculously useful
and has made interactive javascript more accessible to the mainstream.

>
The primary reason I balk at using jQuery or similar libraries is that
a great deal of the basic, cross-browser functionality required for a
specific job can be accomplished in very much less code.  Other really
helpful bits like 'each' are pretty simple to do and seem prime
candidates to be added in the next version of ECMAScript.  So much of
what libraries do is easily replaced using standard javascript that
anyone should be able to maintain, I don't need a jQuery (or Dojo or
Prototype.js) specialist.
>
I'm not a fan of highly active user interfaces - I really dislike
things that fade in and out or slide up and down or popup tool tips.
Therefore many of the animation and special effects are of no use to
me.
>

I'm in favor of it. And I'm in favor of improving it, because it is
quickly becoming a tool that is used by many people.

>

Some important points for me:

>

1) It works. I know it has some internal problems like browser
sniffing and code that isn't as accurate as it should be. But in every
case where I have decided to use it, it has worked and worked well in
most cases. Argue all you want about it being 1px off or slow or how
it _could_ work in browser X if it just didn't browser sniff... but in
reality, in many cases, it works and works well.

>
I would feel more comfortable with that if there was evidence that
such issues were being actively addressed, but there seems to be more
browser sniffing with each release (there are about 30 in v1.2.6).
Guess Nokia are hoping that the special stuff for "webkit" aka Safari
will suit its browser (there are about 10 sniffs specific to Safari,
some for specific version numbers).
>

2) It's supported. The discussion lists are very active and there is a
huge community around it. It's under constant development. Momentum is
in its favor. That's a good thing.

>
The volume of discussion on lists isn't much of an indication,
typically there is a large bubble at the beginning that tapers off.
Nor does it indicate the quality of response (in fact it can show the
reverse).  A good percentage of posts don't get answered at all.
>
A better indication is the frequency of updates and bug fixes and the
availability of well-written books, articles and tutorials.  I can't
comment on that, but the documentation on the jQuery web site leaves a
lot to be desired.
>

3) It encourages unobtrusive scripting. Sometimes too much, IMO. But
by its nature it encourages people to put classes on their HTML tags
and add the behavior after the page is ready. It doesn't encourage all
the best practices, but it's a step in the right direction.

>
Putting aside my dislike of the term "unobtrusiv e scripting", I don't
think it necessarily encourages it more than say putting scripts at
the bottom of the page.
>
Once you start attaching behaviour based on some form of general
selector (even something as simple as a home-grown
getElementsByCl assname function), it’s hard to go back to in-line or
specific functions to do the job.  I would argue that a lot of such
functionality can be similarly processed at the server and a simple in-
line listener added, but that’s for another discussion that would
likely end in “horses for courses”.
>

4) Plugins are questionable. The base jQuery library has a lot of
fundamentals, but if you want "controls" then you need to venture into
the plugin territory. And sometimes this is bad news. The quality of
the plugins is, generally, much lower than jQuery itself, IMO. Be
careful what you use. In some cases, I have been writing my own
because the ones that exist aren't good enough.

>
This is supposed to be a "for" list. :-)
>
I think plugins are the major benefit for many users (i.e. web page
authors), anyone who is unconcerned about the issues of using jQuery
is likely not fussed by the issues of using poorly written plugins
(that is not to say all plugins are poorly written, just that users
don’t really care, just so long as “it works” in maybe 4 different
browsers where IE is two of them).
>

I don't think jQuery (or any general-purpose lib) is the right tool
for everyone. If you have the skill, time, and money to build all your
components from scratch, then go for it. For everyone else, I think
jQuery is the best possible route to go right now and the foreseeable
future.

>
If it replaces the massive bloat that comes with .NET by default, that
has to be a tick in its favour.
>
--
Rob

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.
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.
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,
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
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
out of the way, and makes my own coding both easier, and smaller.
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.
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.

Paul Hanlon.

[Bruno Desthuilliers]

[OT] Re: Is jQuery worth a second look?

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]

Re: Is jQuery worth a second look?

On Oct 2, 10:33 am, PaulHan <paulthan...@gm ail.comwrote:
[snip]

>
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]

Re: Is jQuery worth a second look?

On Sep 28, 6:24 pm, RobG <rg...@iinet.ne t.auwrote:

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 someStupidOverl oadedArgument == '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]

Re: Is jQuery worth a second look?

David Mark wrote:

On Sep 28, 6:24 pm, RobG <rg...@iinet.ne t.auwrote:

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

That was removed several months ago.

The current discussion is along the lines of Object.prototyp e.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.prototyp e.toString.appl y(o).
They'll may end up realizing that call is faster in Firefox (well now
they do :-) ).

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

Which is guaranteed to work, unless someone goes and replaces
Object.prototyp e.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.prototyp e.toString will still have the DontEnum attribute.

This will work for Function and RegExp objects, too:

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


Garrett

[David Mark]

Re: Is jQuery worth a second look?

On Oct 9, 10:58 pm, dhtml <dhtmlkitc...@g mail.comwrote:

David Mark wrote:

On Sep 28, 6:24 pm, RobG <rg...@iinet.ne t.auwrote:

>

if (typeof someStupidOverl oadedArgument == '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.prototyp e.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.prototyp e.toString.appl y(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.prototyp e.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.prototyp e.toString as in:http://groups.google.com/group/comp..../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.prototyp e.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.prototyp e.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.