Is jQuery worth a second look?

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

RobG <rgqld (AT) iinet (DOT) net.au> writes:

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/

On Sep 29, 8:36*am, Joost Diepenmaat <jo... (AT) zeekat (DOT) nl> wrote:

RobG <rg... (AT) iinet (DOT) net.au> writes:
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

RobG wrote:

On Sep 29, 8:36 am, Joost Diepenmaat <jo... (AT) zeekat (DOT) nl> wrote:
RobG <rg... (AT) iinet (DOT) net.au> writes:
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

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

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

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

On Sep 30, 12:13*am, dhtml <dhtmlkitc... (AT) gmail (DOT) com> wrote:

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

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).

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)