Is jQuery worth a second look?

R

RobG

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/jquery-microsoft-nokia/ >
 
J

Joost Diepenmaat

RobG said:
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)
 
R

RobG

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.

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

dhtml

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



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.

Good question. I think it's time for a code review.
 
S

sasuke

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
 
D

dhtml

Conrad said:
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
 
K

kangax

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/jquery/src/core.js#L617
 
H

Henry

On Sep 30, 12:13 am, 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].
<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).
 
B

Bruno Desthuilliers

Henry a écrit :
On Sep 30, 12:13 am, 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].
<snip>

Unreleased development code is irrelevant.

I beg to somewhat disagree. It at least gives indications about the
current direction.

(snip)
 
T

Thomas 'PointedEars' Lahn

kangax said:
dhtml said:
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
 
M

Matt Kruse

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
 
M

Matt Kruse

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
 
O

Oltmans

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

dhtml

Oltmans said:
kangax said:
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
 
D

dhtml

kangax said:
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.

 
H

Henry

kangax said:
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.
 
H

Henry

kangax said:
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.
 
O

Oltmans

Oltmans said:
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.
 
R

RobG

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

Matt Kruse

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,766
Messages
2,569,569
Members
45,042
Latest member
icassiem

Latest Threads

Top