By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,831 Members | 1,031 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,831 IT Pros & Developers. It's quick & easy.

Is jQuery worth a second look?

P: n/a
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.

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
supported library?

<URL: http://jquery.com/blog/2008/09/28/jq...crosoft-nokia/ >
--
Rob
Sep 28 '08 #1
Share this Question
Share on Google+
26 Replies


P: n/a
RobG <rg***@iinet.net.auwrites:
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.
Why would they need to "support" it? It ought to be cross-platform
already. Right?

Oh, I see... MS and Nokia are talking about *using* it. Not sure if
that's much of an endorsement.
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
supported library?
FTR: I'm not against libraries at all. It's just that most I've looked
at solve the wrong problems and/or solve a small subset of interesting
problems in quite a convoluted and ugly way (I'm looking at you,
Prototype.js)

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Sep 28 '08 #2

P: n/a
On Sep 29, 8:36*am, Joost Diepenmaat <jo...@zeekat.nlwrote:
RobG <rg...@iinet.net.auwrites:
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.

Why would they need to "support" it? It ought to be cross-platform
already. Right?
"Support" as in encourage developers on their platforms to use it.

Oh, I see... MS and Nokia are talking about *using* it. Not sure if
that's much of an endorsement.
They've gone a bit further than that, they are supporting it with
their development tools. Microsoft is including an intellisense-
annotated version in Visual Studio and not developing competing
components, Nokia are putting in in their "Web Run-Time" for their
WebKit-based browser running on Symbian and basing their built-in
widgets on it.

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
supported library?

FTR: I'm not against libraries at all. It's just that most I've looked
at solve the wrong problems and/or solve a small subset of interesting
problems in quite a convoluted and ugly way (I'm looking at you,
Prototype.js)
Prototype.js supporters seem a bit intimidated by the success of
jQuery. It's strategy of extending a native object rather
Prototype.js's extension of host objects seems to be a better choice.
--
Rob
Sep 28 '08 #3

P: n/a
RobG wrote:
On Sep 29, 8:36 am, Joost Diepenmaat <jo...@zeekat.nlwrote:
>RobG <rg...@iinet.net.auwrites:
>>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.
Why would they need to "support" it? It ought to be cross-platform
already. Right?

"Support" as in encourage developers on their platforms to use it.

>Oh, I see... MS and Nokia are talking about *using* it. Not sure if
that's much of an endorsement.

They've gone a bit further than that, they are supporting it with
their development tools. Microsoft is including an intellisense-
annotated version in Visual Studio and not developing competing
components, Nokia are putting in in their "Web Run-Time" for their
WebKit-based browser running on Symbian and basing their built-in
widgets on it.

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
supported library?
Good question. I think it's time for a code review.
>

--
Rob
Sep 29 '08 #4

P: n/a
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
supported library?

Good question. I think it's time for a code review.
Just what I've been thinking. JQuery has often been summarily
disqualified as "bad" in this group, but looking back the issues mostly
seemed to center around how it's implemented, not how it's designed or
what it's meant to be doing. At the moment, my experience with JQuery is
pretty much limited to fixing bugs in other people's code (like Drupal
modules, for example), and it may be time to take a closer look again.
I'm sure that much of the criticism is justified. There were a couple of
postings highlighting inefficient or incomplete or plain buggy passages
in the JQuery core, and it seems to me that submitting patches may be
more productive in the long term than cultivating our negative opinion
of this library, and dismissing all JQuery related questions in this
group with short "bad idea" replies.

Some things may be impossible to fix at this point, like the naming of
the "$" constructor. Personally, I don't have a problem with $(), even
though it's not what the $-prefix for identifiers was originally meant
for, but then I've always been more interested in pragmatic solutions.
- Conrad
Sep 29 '08 #5

P: n/a
Another toolkit/library worth looking at is extJS. Though it has a
large memory footprint and considerable size, it is good choice for
developing extreme JS dependent eye candy applications which require
you to have a toolkit which provides almost every conceivable way you
can use Javascript out of the box. A real good choice for intranet UI
intensive web based applications.

On the other hand, if one is looking for an extremely lightweight
library which though doesn't provide everything but still allows you
to build up on itself and drastically cut down boiler plate code,
DOMAssistant is a nice toolkit to look at.

<http://extjs.com/>
<http://www.domassistant.com/>

/sasuke
Sep 29 '08 #6

P: n/a
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
supported library?
Good question. I think it's time for a code review.

Just what I've been thinking. JQuery has often been summarily
disqualified as "bad" in this group, but looking back the issues mostly
seemed to center around how it's implemented, not how it's designed or
what it's meant to be doing. At the moment, my experience with JQuery is
pretty much limited to fixing bugs in other people's code (like Drupal
modules, for example), and it may be time to take a closer look again.
I'm sure that much of the criticism is justified. There were a couple of
postings highlighting inefficient or incomplete or plain buggy passages
in the JQuery core, and it seems to me that submitting patches may be
more productive in the long term than cultivating our negative opinion
of this library, and dismissing all JQuery related questions in this
group with short "bad idea" replies.

What is this?

else {
var fn = jQuery.expr[ m[1] ];
if ( typeof fn == "object" )
fn = fn[ m[2] ];

if ( typeof fn == "string" )
fn = eval("false||function(a,i){return " + fn + ";}");

// Execute it against the current filter
r = jQuery.grep( r, function(elem, i){
return fn(elem, i, m, r);
}, not );
}

This is apparently so a string can be passed in for evaluation in the
'grep' function. Passing in a function would seem to be a better solution.

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.

The jQuery offsets function still uses with() to augment scope with
jQuery.browser, uses an add() and border() functions inside two loops.
That will be slow and I've tested it to be slow, so it's not just
conjecture.

The |clean| function is a little strange.

The jQuery library uses tabs for indentation, has few comments, uses
very short names (e.g. from that function I excerpted, there are all of:
m, r, t, a, z, variables). Despite this, the uncompressed source still
comes in at nearly 100k. Just for the base library.

I would, given a problem, try to use the most appropriate strategy to
solve it.

That is the answer I provide when asked which library I like best. The
person asking will sometimes react incredulously. I have been asked (as
a follow-up question) why I would use such a non-standard approach
instead of using a library.

Garrett
>
- Conrad
Sep 30 '08 #7

P: n/a
On Sep 30, 12:13*am, dhtml <dhtmlkitc...@gmail.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
supported library?
Good question. I think it's time for a code review.
Just what I've been thinking. JQuery has often been summarily
disqualified as "bad" in this group, but looking back the issues mostly
seemed to center around how it's implemented, not how it's designed or
what it's meant to be doing. At the moment, my experience with JQuery is
pretty much limited to fixing bugs in other people's code (like Drupal
modules, for example), and it may be time to take a closer look again.
I'm sure that much of the criticism is justified. There were a couple of
postings highlighting inefficient or incomplete or plain buggy passages
in the JQuery core, and it seems to me that submitting patches may be
more productive in the long term than cultivating our negative opinion
of this library, and dismissing all JQuery related questions in this
group with short "bad idea" replies.

What is this?

* * * *else {
* * * * *var fn = jQuery.expr[ m[1] ];
* * * * *if ( typeof fn == "object" )
* * * * * *fn = fn[ m[2] ];

* * * * *if ( typeof fn == "string" )
* * * * * *fn = eval("false||function(a,i){return " + fn + ";}");

* * * * *// Execute it against the current filter
* * * * *r = jQuery.grep( r, function(elem, i){
* * * * * *return fn(elem, i, m, r);
* * * * *}, not );
* * * *}

This is apparently so a string can be passed in for evaluation in the
'grep' function. *Passing in a function would seem to be a better solution.

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.
The jQuery offsets function still uses with() to augment scope with
jQuery.browser, uses an add() and border() functions inside two loops.
* That will be slow and I've tested it to be slow, so it's not just
conjecture.

The |clean| function is a little strange.

The jQuery library uses tabs for indentation, has few comments, uses
very short names (e.g. from that function I excerpted, there are all of:
m, r, t, a, z, variables). Despite this, the uncompressed source still
comes in at nearly 100k. Just for the base library.

I would, given a problem, try to use the most appropriate strategy to
solve it.

That is the answer I provide when asked which library I like best. *The
person asking will sometimes react incredulously. *I have been asked (as
a follow-up question) why I would use such a non-standard approach
instead of using a library.

Garrett

[1] http://dev.jquery.com/browser/trunk/...c/core.js#L617

--
kangax
Sep 30 '08 #8

P: n/a
On Sep 30, 6:23 am, kangax wrote:
On Sep 30, 12:13 am, dhtml wrote:
<snip>
>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].
<snip>

Unreleased development code is irrelevant. Nobody in their right mind
will be using it on public web sites and where it differs from
previously released code there is no way to tell whether changes won't
need to be reversed (say, in the event that they turn out not to be
back-compatible and/or effective when (and if) fully tested). It is
the code that is released that should be judged (and so if the authors
want to be judged as having corrected some of their mistakes then they
should release a new version).
Sep 30 '08 #9

P: n/a
Henry a écrit :
On Sep 30, 6:23 am, kangax wrote:
>On Sep 30, 12:13 am, dhtml wrote:
<snip>
>>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].
<snip>

Unreleased development code is irrelevant.
I beg to somewhat disagree. It at least gives indications about the
current direction.

(snip)
Sep 30 '08 #10

P: n/a
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.
PointedEars
Sep 30 '08 #11

P: n/a
On Sep 28, 5:24*pm, RobG <rg...@iinet.net.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.
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.

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.

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.

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.

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.

Matt Kruse

Sep 30 '08 #12

P: n/a
On Sep 29, 11:13*pm, dhtml <dhtmlkitc...@gmail.comwrote:
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.
I'm not sure why this hasn't been updated. I posted a more reliable
fix for isFunction quite some time ago but it seemed to be ignored. I
think perhaps because the existing code really only fails in odd,
isolated cases.
The jQuery library uses tabs for indentation, has few comments, uses
very short names (e.g. from that function I excerpted, there are all of:
m, r, t, a, z, variables). Despite this, the uncompressed source still
comes in at nearly 100k. Just for the base library.
True, it has grown quite a bit larger than its original intent. I use
the minified version in production, which is just about 50k. I've
never been in a situation where that was a problem.

Matt Kruse
Sep 30 '08 #13

P: n/a
On Sep 30, 6:38 pm, "Thomas 'PointedEars' Lahn" <PointedE...@web.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.

Thanks in advance.
PointedEars
Sep 30 '08 #14

P: n/a
Oltmans wrote:
On Sep 30, 6:38 pm, "Thomas 'PointedEars' Lahn" <PointedE...@web.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.html"></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
Sep 30 '08 #15

P: n/a
kangax wrote:
On Sep 30, 12:13 am, dhtml <dhtmlkitc...@gmail.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
>>supported 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
Sep 30 '08 #16

P: n/a
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.
Sep 30 '08 #17

P: n/a
On Sep 30, 5:45 pm, dhtml <dhtmlkitc...@gmail.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.
Sep 30 '08 #18

P: n/a
On Sep 30, 9:44 pm, dhtml <dhtmlkitc...@gmail.comwrote:
Oltmans wrote:
On Sep 30, 6:38 pm, "Thomas 'PointedEars' Lahn" <PointedE...@web.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.html"></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.
Sep 30 '08 #19

P: n/a
On Oct 1, 1:04 am, Matt Kruse <m...@thekrusefamily.comwrote:
On Sep 28, 5:24 pm, RobG <rg...@iinet.net.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 "unobtrusive 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
getElementsByClassname 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
Oct 1 '08 #20

P: n/a
On Sep 30, 10:25*pm, RobG <rg...@iinet.net.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 "unobtrusive 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
Oct 1 '08 #21

P: n/a
On Oct 1, 4:25*am, RobG <rg...@iinet.net.auwrote:
On Oct 1, 1:04 am, Matt Kruse <m...@thekrusefamily.comwrote:
On Sep 28, 5:24 pm, RobG <rg...@iinet.net.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 "unobtrusive 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
getElementsByClassname 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.
Oct 2 '08 #22

P: n/a
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 !-)

Oct 2 '08 #23

P: n/a
On Oct 2, 10:33 am, PaulHan <paulthan...@gmail.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.
Oct 9 '08 #24

P: n/a
On Sep 28, 6:24*pm, RobG <rg...@iinet.net.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 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.)
Oct 10 '08 #25

P: n/a
David Mark wrote:
On Sep 28, 6:24 pm, RobG <rg...@iinet.net.auwrote:
>
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....b?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
Oct 10 '08 #26

P: n/a
On Oct 9, 10:58*pm, dhtml <dhtmlkitc...@gmail.comwrote:
David Mark wrote:
On Sep 28, 6:24 pm, RobG <rg...@iinet.net.auwrote:
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..../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.
Oct 10 '08 #27

This discussion thread is closed

Replies have been disabled for this discussion.