JSLint Reports on last 2 Production Versions of jQuery

[Garrett Smith]

[...]


But having said all that, I want to say again that I still use jQuery
and recommend it.

Yes, I know you do, but do not understand why.

These criticisms are really coming from very experienced js developers
who understand all the fine points of the language and implementation.
jQuery is a good product for the common Joe Coder, but it will _never_
meet the standards of those who are the true wizards of the language.
I don't expect it to.

jQuery is good for simple stuff, grabbing elements by selectors,

The amount of code required to make possible css-selector queries is not
worth the amount of convenience it adds.

doing

things like hiding and showing and animating, etc. That's what I
mostly use it for, and that's what I recommend it for. I never
recommend writing complex interfaces "in jQuery". I may fall back to
its selector engine, and I may add my own methods that are optimized
to do what I want, but I don't use the UI components or almost any of
the 3rd-party plugins. I don't do things "the jQuery way". I don't
focus on writing dense code but instead code that is logical and easy
to read and understand.

So jQuery is good for simple things but not complicated things, huh? Can
you show us an example?

jQuery is javascript for the masses. And it's great for that, IMO.
Once you progress beyond that and learn more, you will naturally see
its flaws.

Or maybe you started out studying and reading the pertinent standards
and jQuery is irrelevant to solving simple problems and probably a bad
choice for building sophisticated applications.

Then you'll move to something else. Which is great! jQuery

is the first step for most people. Without it, they may not move up at
all. It serves its purpose, even if imperfect.

If jQuery is the starting point, then how do you propose one advance
from that?

I fail to see how jQuery is good starting point for progressing to learn
how to program rich web interfaces.

Based on what you've written, you seem to indicate that you have not
moved on, but still in fact do use jQuery for simple things.

I recommend a different strategy: Read the pertinent standards (they are
listed in the FAQ), and study OOP and Agile programming, as it pertains
to TDD, interface design, and code organization.

Disclaimer: I am not a "wizard" just a guy who RTFM.

"Everybody wants to be a bodybuilder but nobody wants to lift no heavy
ass weights".

 

[Garrett Smith]

[...]

What do you think I meant?

I thought you meant variable name.

It's still a stupid name.

The comment in the code made sense to me. I understand why they do that.
They want undefined to be munged and faster lookup. The outcome should
be slightly smaller and slightly faster, and the code still looks
"normal" in the sense of comparing things to `undefined` in un-minified
code.

The only downside would be to rely on using `undefined` instead of
typeof, where the typeof helps swallow an error.

[...]

ASI = Automatic Semicolon Insertion. If the JSON response begins with a
line terminator.
Yes.

[example]

So it's safer to to use grouping operator there.

Okay, but it that is not how your example reads.

Typo, BTW.

Yes, but if responseText has the json after a line terminator, the
function will end up returning undefined.

Some APIs encourage the use of JSONP via dynamic script loading.

http://suggestqueries.google.com/complete/search?qu=****&jsonp=while
while(["****",[]])

Profanity results in a cleaner example here, the "while" method is a
joke. No innuendos there.

For XHR, a proxy would need to be used. If the proxy introduces a line
terminator -- and it is very easy to do this inadvertently -- then the
fist statement in the function would be "return", and the result of that
function would be to return undefined.

If it sounds like I tripped over this before -- I did.

It does not matter what "causes" the problem (as if either side can be
given more weight). The fact exists that the problem is out there on
the Web.


That's self-evident, but still bad advice.

I don't really agree. I think modifying Object.prototype is wrong. If
you, the developer, add a script that modifies Object.prototype, my API
will not work properly. That is my contract to you.


[...]

Why would anyone in their right mind use Dojo? Mass hysteria?

"We don't have time to write everything from scratch".
"There's no sense in reinventing the wheel".
"There is a lot of functionality that we can leverage".

Well that's the reasons I've been given. Writing a javascript library is
time consuming and the manager faced with a project wants to use
*something* and if Dojo is something of an industry standard, then that
becomes an option.

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
lorlarz wrote:
On 02/03/10 01:32, lorlarz wrote:

[...]

What do you think I meant?

I thought you meant variable name.

It's still a stupid name.

The comment in the code made sense to me. I understand why they do that.
They want undefined to be munged and faster lookup. The outcome should
be slightly smaller and slightly faster, and the code still looks
"normal" in the sense of comparing things to `undefined` in un-minified
code.

How is it a good idea to make code look like something it is not?

The only downside would be to rely on using `undefined` instead of
typeof, where the typeof helps swallow an error.

And readers thinking - undefined - is something that it isn't.

[...]

// Use grouping operator to avoid ASI-related error.
Huh?

ASI = Automatic Semicolon Insertion. If the JSON response begins with a
line terminator.
Yes.

[example]

So it's safer to to use grouping operator there.

Okay, but it that is not how your example reads.

var f = new Function("return("+responseText");");

Typo, BTW.

Yes, but if responseText has the json after a line terminator, the
function will end up returning undefined.

Yes, unless you stripped the leading line terminator. But what does any
of this have to do with the above example (which has a typo?)

Some APIs encourage the use of JSONP via dynamic script loading.
Yes.


http://suggestqueries.google.com/complete/search?qu=****&jsonp=while
while(["****",[]])

Profanity results in a cleaner example here, the "while" method is a
joke. No innuendos there.

I don't follow that at all. How is using a profanity "cleaner" and what
is the joke?

For XHR, a proxy would need to be used. If the proxy introduces a line
terminator -- and it is very easy to do this inadvertently -- then the
fist statement in the function would be "return", and the result of that
function would be to return undefined.
Yes.


If it sounds like I tripped over this before -- I did.

That's how you learn about things. I've heard of these issues, but I
can't make heads of tails of any of your examples.

I don't really agree. I think modifying Object.prototype is wrong. If
you, the developer, add a script that modifies Object.prototype, my API
will not work properly. That is my contract to you.

It's not about right and wrong. It's about the reality of deploying a
script on the Web (at least for scripts that must run on any random page).

[...]

Why would anyone in their right mind use Dojo? Mass hysteria?

"We don't have time to write everything from scratch".

Well, get some programmers who aren't fresh off the banana boat and you
very likely won't be writing much of anything from scratch (and you sure
as hell won't be using Dojo!)

"There's no sense in reinventing the wheel".

See previous answer and realize that Dojo is not a wheel. It's a whole
bunch of mostly unrelated scripts, most (especially at its core) are
inarguably rotten and clearly written by people who are both unfamiliar
with Javascript and certainly new to the world of cross-browser
scripting. They certainly haven't invented any wheels, they don't have
any wheel blueprints and as somebody who has been through _all_ of their
code, it is my studied opinion that they wouldn't recognize a wheel as
such if they saw one. Furthermore, based on interactions with their
developers, I don't see this changing ever. They say they are working
on some wildly new version for release in 2011 or something, but why
would anyone wait around for that bunch to put out another load of drivel?

"There is a lot of functionality that we can leverage".

You'll leverage yourself right into bankruptcy. The stuff is all based
on browser sniffing, so you will be in maintenance hell forever. Do you
really want to be asking them why your app has broken (again) and be
told that it is because version xyz never claimed to support IE9 (or
IE10 or Safari 5 or whatever). Furthermore, do you want to have to
explain to your visitors after the requisite "upgrade" fails to support
IE8 (or Safari 4 or whatever) that they are out of luck if they can't
immediately upgrade their browsers? And what about browsers that the
Dojo developers have never heard of or "don't care" about? You'll find
that visitors using those browsers will dutifully stop caring about your
sites. Of course it is a moot point as the whole bloated mess is
perfectly unsuitable for use on the Web anyway, which is why you never
see it out there. No amount of disingenuous "wowie" marketing (as
recently proposed in their forum) is going to make people mistake it for
something usable.

Well that's the reasons I've been given. Writing a javascript library is
time consuming and the manager faced with a project wants to use
*something* and if Dojo is something of an industry standard, then that
becomes an option.

And what defines an "industry standard?" Wide-spread use. Scratch
that. Perhaps some small portion of it is best in class? Not even
close. Take two examples, queries and Flash. Dojo's is renditions are
awful and unusable respectively. Of course, you can build your own
library with far better modules at:-

http://www.cinsoft.net/mylib.html

....and get support from me, rather than the people who wrote Dojo. It's
a no-brainer. Dojo has more modules, but quantity doesn't count for
much in this business, particularly when people aren't going to need
anywhere near all of them. Their modularity is a joke (everything
requires virtually everything else) and their widgets are so obviously
incompetent as to insult your intelligence (e.g. slow as molasses,
crawling with browser sniffs, accessibility nightmares, primary "owner"
of them is demonstrably out of his mind, etc.)

I could go on and on about Dojo and "Dijit" and the rest of their
bullshit and I very likely will. Libraries and the loose nuts behind
them are themes of the new site I've been working on. The two test
pages and counterpoint example library are just for starters. A review
of Dojo 1.4 will be one of the first features and will also be the first
one I've done on the Web (with lots of pretty code examples) rather than
on Usenet. Anyone who can get all the way through it and still thinks
Dojo is a good idea would have to be... well, one of the Dojo authors.

 

[Garrett Smith]

Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
lorlarz wrote:
On 02/03/10 01:32, lorlarz wrote: [...]

What do you think I meant?

I thought you meant variable name.

I saw undefined used as a variable name. The reasons were given so that
it would be munged and would be faster lookup.
It's still a stupid name.

The comment in the code made sense to me. I understand why they do that.
They want undefined to be munged and faster lookup. The outcome should
be slightly smaller and slightly faster, and the code still looks
"normal" in the sense of comparing things to `undefined` in un-minified
code.

How is it a good idea to make code look like something it is not?

The only downside would be to rely on using `undefined` instead of
typeof, where the typeof helps swallow an error.

And readers thinking - undefined - is something that it isn't.

The value is the same as window.undefined.

[...]

// Use grouping operator to avoid ASI-related error.
Huh?

ASI = Automatic Semicolon Insertion. If the JSON response begins with a
line terminator.
Yes.
[example]

So it's safer to to use grouping operator there.
Okay, but it that is not how your example reads.

var f = new Function("return("+responseText");");
Typo, BTW.

Yes, but if responseText has the json after a line terminator, the
function will end up returning undefined.

Yes, unless you stripped the leading line terminator. But what does any
of this have to do with the above example (which has a typo?)

Some APIs encourage the use of JSONP via dynamic script loading.
Yes.

http://suggestqueries.google.com/complete/search?qu=****&jsonp=while
while(["****",[]])

Profanity results in a cleaner example here, the "while" method is a
joke. No innuendos there.

I don't follow that at all. How is using a profanity "cleaner" and what
is the joke?

No, if you try a non-profane word:
http://suggestqueries.google.com/complete/search?qu=****&jsonp=while

Then the resulting jsonp function call arg has a lot of results.

[...]

I read through the rest but did not have time to reply.

 

[David Mark]

David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
Garrett Smith wrote:
David Mark wrote:
lorlarz wrote:
On 02/03/10 01:32, lorlarz wrote:
[...]

What do you think I meant?

I thought you meant variable name.

I saw undefined used as a variable name. The reasons were given so
that
it would be munged and would be faster lookup.
It's still a stupid name.

The comment in the code made sense to me. I understand why they do that.
They want undefined to be munged and faster lookup. The outcome should
be slightly smaller and slightly faster, and the code still looks
"normal" in the sense of comparing things to `undefined` in un-minified
code.

How is it a good idea to make code look like something it is not?

The only downside would be to rely on using `undefined` instead of
typeof, where the typeof helps swallow an error.

And readers thinking - undefined - is something that it isn't.

The value is the same as window.undefined.

Yes, the value is. Still seems like a silly idea to use that name as
the local identifier.

[...]

// Use grouping operator to avoid ASI-related error.
Huh?

ASI = Automatic Semicolon Insertion. If the JSON response begins
with a
line terminator.
Yes.

[example]

So it's safer to to use grouping operator there.
Okay, but it that is not how your example reads.

var f = new Function("return("+responseText");");
Typo, BTW.

Yes, but if responseText has the json after a line terminator, the
function will end up returning undefined.

Yes, unless you stripped the leading line terminator. But what does any
of this have to do with the above example (which has a typo?)

Some APIs encourage the use of JSONP via dynamic script loading.
Yes.

http://suggestqueries.google.com/complete/search?qu=****&jsonp=while
while(["****",[]])

Profanity results in a cleaner example here, the "while" method is a
joke. No innuendos there.

I don't follow that at all. How is using a profanity "cleaner" and what
is the joke?

No, if you try a non-profane word:
http://suggestqueries.google.com/complete/search?qu=****&jsonp=while

Then the resulting jsonp function call arg has a lot of results.

Okay. And yeah, at second glance I get the joke, but why make a joke in
an example?

[...]

I read through the rest but did not have time to reply.

I don't remember what the rest was.

 

[Andrea Giammarchi]

JSLint does not accept more prepared/expert developers and I don't get
all this fuss around JSLint.

I have already commented "JSLint The Bad Part" and everybody seems to
agree about the fact JSLint is for Junior, is an extra hint during
development, but surely it's not the bible.

The == null is a JSLint *error*, specs clearly says that there is NO
COERCION against null.

null == undefined AND null == null are the only TRUE value, everything
else compared with null and == will be FALSE.

The only thing that JSLint should do to avoid blames against
developers that MEANT something, is a bloody flag:

/*jslint ignore:true*/ ... the code you meant like that ... /*jslint
ignore:false*/

or

/*jslint meant:true*/ ... the code you meant like that ... /*jslint
meant:false*/

This will make JSLint useful to get all "gotchas" and document or
ignore all those piece of code that should be exactly like that.

This will make good JS code as jQuery is valid and will make all those
developers unable to understand WHY IT'S NOT AN ERROR happy (plus
automation against validation)

I tried to sign into the JSLint group but AFAIK I am not in yet to
propose this change.

Regards

 

[David Mark]

JSLint does not accept more prepared/expert developers and I don't get
all this fuss around JSLint.

What does that first part mean?

I have already commented "JSLint The Bad Part" and everybody seems to
agree about the fact JSLint is for Junior, is an extra hint during
development, but surely it's not the bible.

It's good for spotting mistakes (like typos), as well as ambiguous and
or potentially problematic structures. It's not meant to be a bible.
You should be able to interpret the results, else it will just confuse you.

The == null is a JSLint *error*, specs clearly says that there is NO
COERCION against null.

null == undefined AND null == null are the only TRUE value, everything
else compared with null and == will be FALSE.

You would seem to have (loudly) contradicted yourself. Two (2)
warnings, unable to continue.

 

[Richard Cornford]

Matt Kruse wrote:

Or maybe you started out studying and reading the pertinent
standards and jQuery is irrelevant to solving simple problems
and probably a bad choice for building sophisticated applications.

Then you'll move to something else. Which is great! jQuery


If jQuery is the starting point, then how do you propose one
advance from that?

I fail to see how jQuery is good starting point for progressing
to learn how to program rich web interfaces.

<snip>

It may be the case that buying the JQuery story necessitates (or
results in) a skewing of perceptions that is ultimately counter
productive. A situation where to advance (to achieve what one
perceives as advanced) does not involve that much movement (or effort)
at all.

An example of this that I recently noticed is this blog article:-

<URL: http://milanadamovsky.blogspot.com/2010/02/new-jquery-plugin-pattern.html
- which propose a "New jQuery Plugin Pattern" as an 'improvement' to a
previous effort by the same author, which he titled "Advanced jQuery
Plugin Authoring Pattern". So theoretically the new article represents
an advance on "advanced".

The article's "pattern" includes the code:-

$.fn.pluginName = function ()
{
return(this);
}.apply(this);
};

- with the explanation: "We overwrite our newly defined plug-in to be
a "clean" anonymous function in the form of a closure.", showing an
apparent unawareness that the above code is the equivalent of:-

$.fn.pluginName = this;

- and that the anonymous function is immediately available for garbage
collection and so does not involve itself in any closures.

What this code is doing is certainly not what its author thinks it is
doing, which would be revealed if it were tested more than
superficially.

Now this is an author who considers himself to have a high enough
status/position to be a suitable instructor for others. In another
article of his, at:-

<URL: http://milanadamovsky.blogspot.com/2010/02/one-space-indentation.html
- he writes:-

"This article is for Enterprise level developers."
"... but if you consider yourself at least a senior developer that's
another story."
"... and should not be used in advanced code."
"Here we will explore how to code like a pro."

Yet while displaying this attitude, and trying to instruct others on
how they could 'advance', he doesn't actually understand the code he
is writing.

Bamboozling juniors and clients is one thing (not to be approved of,
but still), but bamboozling yourself is crazy. Especially when it
requires active intervention to maintain the illusions. You might
wonder were the comment for the "New jQuery Plugin Pattern" article
are that point out that the code does not do what its author thinks it
does. It could be that a JQuery-centric audience does not know any
better, but I posted such a comment so I know that there were more
than none. I suppose that this is a case of pointing out that an
author did not know what he was talking about did no qualify as
"constructive criticism" and so such a comment is censored on those
grounds. But still, the act of censoring might have tipped the blog's
author off that something was wrong with the code.

So, if JQuery is the starting point then "how do you advance" is a
very good question when it turns out that the JQuery users who
perceive themselves as having advanced are letting themselves go off
down blind alleys because they don't understand the javascript they
write (and apparently don't know how to appropriately test it either).

Richard.

 

[Scott Sauyet]

It may be the case that buying the JQuery story necessitates (or
results in) a skewing of perceptions that is ultimately counter
productive. A situation where to advance (to achieve what one
perceives as advanced) does not involve that much movement (or effort)
at all.

It's possible that this is the case. But my take is that the quality
of JS found around the web is better than it was before the onset of
the GP libraries. There are still plenty of really poor scripts
floating around (and I'm talking about ones that make jQuery et al
look positively brilliant) but they no longer get the exposure they
used to, as it's become so easy to achieve what these sometimes
massive one-off scripts did using only line or two of jQuery-based
code. (Dojo, MooTools, YUI, whatever.) Sure these libraries to some
degree impose their viewpoints upon their users -- MooTools users are
more likely to look for OO solutions to their problems, jQuery people
always want to "find something, do something" -- but I don't think
that routinely leads to a a counter-productive skewing of
perspectives.

An example of this that I recently noticed is this blog article:-

<URL:http://milanadamovsky.blogspot.com/2010/02/new-jquery-plugin-pattern....

Strange, I commented on the same issue with that pattern in a
different forum a few days ago:

<http://forum.jquery.com/topic/advanced-plugin-authoring-tutorial>

I hadn't looked at his other posts to realize that he was quite
possibly a blowhard. I just assumed he was confused and had left
behind detritus from earlier versions of his work. But I think the
answer is more fundamental: his grasp of JS is fairly tenuous.

So, if JQuery is the starting point then "how do you advance" is a
very good question when it turns out that the JQuery users who
perceive themselves as having advanced are letting themselves go off
down blind alleys because they don't understand the javascript they
write (and apparently don't know how to appropriately test it either).

I think one of the way they advance is to actually wean themselves
away from using their tool of choice, taking with them some of what
they've learned. If they've learned something about using closures to
maintain state from their work with jQuery, perhaps they'll take that
along. If they've learned how to decorate objects with additional
methods from Prototype, maybe they'll take that. If they've learned
how to structure their JS in an OO manner from MooTools, that might be
what they take.

Of course they'll have unlearning to do. But most advancement
involves some degree of unlearning.

There will always be those who perceive themselves as more advanced
than they are. And some of them will obnoxiously trumpet themselves
and the knowledge they think they've acquired. They're likely a very
small minority.

-- Scott

 

[Richard Cornford]

On Mar 4, 4:28 pm, Scott Sauyet wrote:

Strange, I commented on the same issue with that pattern
in a different forum a few days ago:

<http://forum.jquery.com/topic/advanced-plugin-authoring-tutorial>

Is there some point in posting a URL to a page that just says "You
don't have permissions to view this topic!"?

Richard.

 

[Matt Kruse]

Sheesh.  Who sent you on _that_ errand of mercy?

Your habit of trying to point out how _you_ were the root of every
solution, every criticism, and every observation is annoying.

You would really like to use CSS selector queries?  Too bad as they are
not practical at all.

They seem to work very well for me, and are very convenient. I like
them.

The animations have always been sub-standard (and ugly as hell on older
or lesser PC's, phones, etc.)

If I cared about those things, I wouldn't use jQuery for them.

NO.  It isn't.  It's a lousy script that makes browser scripting much
more difficult than it needs to be.  Why would the masses clamor for that?

$('#mydiv').load('feed.php .results',{limit:25});

That is very easy for a casual developer to understand and write, yet
it does quite a bit of stuff under the hood. It's extremely
convenient. They may not realize the caveats, but if they are
developing a simple web site for their child's baseball team or a
quick app to automate a process at work, simple syntax like that
really empowers people to do complex tasks.

So you are now using My Library?

No, and I don't see myself ever doing so.

Matt Kruse

 

[Matt Kruse]

Yes, I know you do, but do not understand why.

I think I've explained it quite a lot. Perhaps you understand the
reasons, but you just don't agree with them. Which is fine, since we
are different people working on different projects in different
environments.

The amount of code required to make possible css-selector queries is not
worth the amount of convenience it adds.

The amount of code doesn't matter to me, so that argument isn't
convincing for me.

So jQuery is good for simple things but not complicated things, huh? Can
you show us an example?

If jQuery is the starting point, then how do you propose one advance
from that?

jQuery will work in most situations, for most people, at a level of
efficiency that is acceptable.
At some point, a developer may find that:
1) Their code is too slow
2) Their code breaks in some browsers
3) Their code breaks under some situations

In these cases, the fault may lie with jQuery, and the developer will
learn ways to unhook jQuery to do some process manually. As they do
that, they will surely be exposed to more advanced js concepts.

I fail to see how jQuery is good starting point for progressing to learn
how to program rich web interfaces.

It may help to just get the job done, instead of forcing someone to
struggle endlessly with how to implement 20 different concepts on
their own. IMO, it's better than downloading snippets from
dynamicdrive or copying examples that may exist in code from 10 years
ago.

jQuery can help someone write javascript and learn that it's not to be
feared. That it is accessible and can do cool things. It's not some
terribly cryptic language that makes no sense and always breaks, as
many people often believe. jQuery can allow someone to have a
successful experience with javascript, rather than fighting it and
hating it.

Based on what you've written, you seem to indicate that you have not
moved on, but still in fact do use jQuery for simple things.

That is moving on. Keep in mind, I don't use jQuery all that often
personally, but it's used in many projects and teams where it is the
best choice. Just because it's not something I often code with doesn't
mean I don't think it fits for other situations.

I recommend a different strategy: Read the pertinent standards (they are
listed in the FAQ), and study OOP and Agile programming, as it pertains
to TDD, interface design, and code organization.

Great plan, for someone who has the time, interest, and capability of
understanding all that. If you need to guide a team of junior
developers through building a web app that will hopefully actually
work at the end of a short development schedule, I doubt your strategy
would be very successful.

Matt Kruse

 

[Gregor Kofler]

Matt Kruse meinte:

jQuery can help someone write javascript and learn that it's not to be
feared. That it is accessible and can do cool things. It's not some
terribly cryptic language that makes no sense and always breaks, as
many people often believe.

No. jQuery won't help anyone to "write and learn" JavaScript. And it is
so popular, *because* JS is perceived as "inherently evil". And jQuery
won't change that perception.

Gregor

 

[Matt Kruse]

Matt Kruse meinte:
No. jQuery won't help anyone to "write and learn" JavaScript. And it is
so popular, *because* JS is perceived as "inherently evil". And jQuery
won't change that perception.

Perhaps. *shrug* I've witnessed the process that I describe, so it
surely happens for some.
As with most things, I doubt there is a single rule of thumb.

Matt Kruse

 

[Scott Sauyet]

On Mar 4, 4:28 pm, Scott Sauyet wrote:



Is there some point in posting a URL to a page that just says "You
don't have permissions to view this topic!"?

Sorry, I didn't realize the it was a members-only group. The new
jQuery forums seem to me a huge step backwards from a plain mailing
list.

If you're curious, the contents of my post are below. It was in
response to a page on the jQuery Plug-In development forum that
described and linked to the article you cited and asked for feedback.

-- Scott
____________________

I guess I'm confused by this. It seems to me that if you try this:

$("#d1, #d2").pluginName.someMethod()

then this:

$("#d3").pluginName.someMethod()

the "this" in the second call would refer to the jQuery object created
in the first call.

What am I missing?

Also, how is this:

$.fn.pluginName = function(){
return this;
}.apply(this);


different from just:

$fn.pluginName = this;

?

Do you have an example plug-in using this architecture?

I really like the idea of making a plug-in that is a namespace for
additional functions. I am not thrilled with the jQuery UI's method
of passing in a string method name for further calls. But the way you
do it seems to me to lose the context. What am I missing?

-- Scott

 

[Garrett Smith]

I think I've explained it quite a lot. Perhaps you understand the
reasons, but you just don't agree with them. Which is fine, since we
are different people working on different projects in different
environments.

I don't remember seeing anything that looked like a reason. Really.

The amount of code doesn't matter to me, so that argument isn't
convincing for me.

I see.

So when you have a script to show an element (as below) and the script
is doing a million other things, in complicated ways with mile-long
methods and 8 levels of indentation, then that's fine with you, so long
as the interface you're using does what you want.

For me, when I step into that method, I want to be able to step through
it quickly, e.g.:

function xxx(f,e) {
debugger;
a(f);
b(e);
if(c) {
d();
}
}

- and so that if I think that I find xxx is causing an error, it becomes
way easier to figure out where, without having to step through a ton of
stuff.

One of the sore spots in jQuery an also in YUI is that it the methods
tend to be very long and complicated.

Simple: <div onclick="$(this).slideToggle()">
Complicated: Google Maps

Computationally showing a div and then setting the height.

Once that is fully hidden, you won't be able to get it back.

Probably I would just use onclick='this.style.display = "none"' for that.

That would seem to fulfill functional use-case requirements at first.
CSS and animations enhancements come next. If

jQuery will work in most situations, for most people, at a level of
efficiency that is acceptable.
At some point, a developer may find that:
1) Their code is too slow
2) Their code breaks in some browsers
3) Their code breaks under some situations

In many cases, the team finds themselves running around like chickens
with their heads cut off, hurrying to patch the bugs they've created
with their shoddy methodologies.

I've seen this in practically every team.

In these cases, the fault may lie with jQuery, and the developer will
learn ways to unhook jQuery to do some process manually. As they do
that, they will surely be exposed to more advanced js concepts.

Well to learn how to do that thing without jQuery would be to learn the
pertinent technologies and then in that case, time was wasted on jQuery
as that step could have just been bypassed.

When I was learning Java, I id not start out writing servlets. Most of
us started out with public static void main, and System,out.println.

It may help to just get the job done, instead of forcing someone to
struggle endlessly with how to implement 20 different concepts on
their own. IMO, it's better than downloading snippets from
dynamicdrive or copying examples that may exist in code from 10 years
ago.

I still fail to see how jQuery is more conducive to learning to develop
RIAs. How is learning jq better than downloading scripts from DD? I fail
to see how either contribute towards learning javascript. And in failing
to see that, I fail to see your point.

jQuery can help someone write javascript and learn that it's not to be
feared. That it is accessible and can do cool things. It's not some
terribly cryptic language that makes no sense and always breaks, as
many people often believe. jQuery can allow someone to have a
successful experience with javascript, rather than fighting it and
hating it.

Until it doesn't do what they want.

That is moving on. Keep in mind, I don't use jQuery all that often
personally, but it's used in many projects and teams where it is the
best choice. Just because it's not something I often code with doesn't
mean I don't think it fits for other situations.


Great plan, for someone who has the time, interest, and capability of
understanding all that. If you need to guide a team of junior
developers through building a web app that will hopefully actually
work at the end of a short development schedule, I doubt your strategy
would be very successful.

I have on many occassions heard the excuse "we don't have time". It is
really common. Managers often say this about pair programming or TDD.

Many if not most RIA ships without doing formal unit-tested for that
excuse. "Too many bugs to fix and we don't have time".

In working with managers and teams who "didn't have time". The projects
either failed or shipped in spite of the problems caused by shipping junk.

However I have not heard what you propose -- "we dont' have time to
/learn/ the pertinent technology". This implies that not only are the
workers learning on the job, but they do not have time to learn on the
job. Are you f**king kidding me?

I must say, I got a laugh out of it. The sad thing is, that with so many
ignorant individuals advocating things like jQUery, it actually almost
sounds like learning the pertinent technologies is an option that can be
avoied, thus saving some time in the initial phases of learning.

If you are interested in doing TDD for a javascript library -- and this
goes for anyone -- you may contribute to APE. The stipulations are that
code gets unit tested and reviewed.

 

[Andrea Giammarchi]

What does that first part mean?

it means that it does not have enough switches and less skilled people
too often think "if JSLint says that, it must be an error"
I do believe 10% of JS devs actually understand JSLint results. 90%
simply code following JSLint suggestion with is BAD, as example, every
time they compare against undefined (JSLint suggests to do not use
global variables then it suggests to use === undefined, which is a
global variable everybody can redefine accidentally or not).

It's good for spotting mistakes (like typos), as well as ambiguous and
or potentially problematic structures.  It's not meant to be a bible.
You should be able to interpret the results, else it will just confuse you.

I have to spend 5 extra minutes every time there is a JSLint
warning ... I have to comment it within the code, even i it could be a
truly simple thing, and to explain it to somebody else when necessary.
This is annoying and time wasting, imho

You would seem to have (loudly) contradicted yourself.  Two (2)
warnings, unable to continue.  

which part is contradiction?
There is NO COERCION against null, it's in specs, it's not me.
Specs say that if a is "null" or "undefined", and b is "null" or
"undefined", this is the only case where a == b will be true.
This is NOT a coercion, a coercion occurs when a type could be
implicitly transformed into another type (eventually passing via
valueOf or toString, if redefined)


If you have other questions please let me know, I'll be happy to
better explain what I mean.

Regards

 

[Richard Cornford]

Sorry, I didn't realize the it was a members-only group. The
new jQuery forums seem to me a huge step backwards from a plain
mailing list.

Certainly restricting the reading of the content seems odd (perhaps
there is money to be made from the user database so it is advantageous
to force as many registrations as possible).

On the other hand, the parts of the new JQuery forum that are readable
function so slowly that I don't have the patience to consider using
that system.

If you're curious,

I am.

the contents of my post are below. It was in response to a page on
the jQuery Plug-In development forum that described and linked to
the article you cited and asked for feedback.

____________________

I guess I'm confused by this. It seems to me that if you try this:

$("#d1, #d2").pluginName.someMethod()

then this:

$("#d3").pluginName.someMethod()

the "this" in the second call would refer to the jQuery object
created in the first call.

Is that how it works? My impression was that at some point someone had
to do something like:-

$(' xxx ').pluginName();

- to set-up the plugin, and it so it was the JQuery object for that
call that replaced the - pluginName - property of - $.fn - (which is
the JQuery prototype). Without that - $(' xxx ').pluginName - would
refer to a function, and not have the plugin methods.

What am I missing?

Also, how is this:

$.fn.pluginName = function(){
return this;
}.apply(this);

different from just:

$fn.pluginName = this;

?

Do you have an example plug-in using this architecture?

I really like the idea of making a plug-in that is a namespace
for additional functions. I am not thrilled with the jQuery
UI's method of passing in a string method name for further
calls. But the way you do it seems to me to lose the context.
What am I missing?

I am glad that someone questioned this in a context that the author
would find hard to dismiss/ignore, but was there any response? I
assume that there was not.

Richard.

 

[Antony Scriven]

What does that first part mean?

it means that it [JSLint] does not have enough switches
and less skilled people too often think "if JSLint says
that, it must be an error" I do believe 10% of JS devs
actually understand JSLint results. 90% simply code
following JSLint suggestion with is BAD,

If a developer doesn't understand JSLint's warnings then it
is probably a good idea for them to be following its
suggestions.

as example, every time they compare against undefined
(JSLint suggests to do not use global variables then it
suggests to use === undefined, which is a global variable
everybody can redefine accidentally or not).

The point of the second suggestion is to use '===', not
'=== undefined' specifically. Both are suggestions are good
advice.

I have to spend 5 extra minutes every time there is
a JSLint warning ... I have to comment it within the
code, even i it could be a truly simple thing, and to
explain it to somebody else when necessary. This is
annoying and time wasting, imho

I'd say that was 5 minutes well spent. Running a colleague's
code through JSLint and then explaining the warnings to them
is a good investment. --Antony

 

[Antony Scriven]

What does that first part mean?

it means that it [JSLint] does not have enough switches
and less skilled people too often think "if JSLint says
that, it must be an error" I do believe 10% of JS devs
actually understand JSLint results. 90% simply code
following JSLint suggestion with is BAD,

If a developer doesn't understand JSLint's warnings then it
is probably a good idea for them to be following its
suggestions.

as example, every time they compare against undefined
(JSLint suggests to do not use global variables then it
suggests to use === undefined, which is a global variable
everybody can redefine accidentally or not).

The point of the second suggestion is to use '===', not
'=== undefined' specifically. Both are suggestions are good
advice.

I have to spend 5 extra minutes every time there is
a JSLint warning ... I have to comment it within the
code, even i it could be a truly simple thing, and to
explain it to somebody else when necessary. This is
annoying and time wasting, imho

I'd say that was 5 minutes well spent. Running a colleague's
code through JSLint and then explaining the warnings to them
is a good investment. --Antony