Test for null or undefined?
Alan Gutierrez
jQuery extension, so maybe there is a best practice specific to
jQuery.
function foo( data, type ) {
if ( type == null ) type = "text"
bar( data, type )
}
Should I be testing for null or undefined?
Alan Gutierrez
Stevo
I wouldn't use the name type, but assuming the name type is OK, then
if(type==undefined) will work. You could also check arguments.length
Thomas Allen
I'd go with checking Arguments.length.
Thomas
David Mark
> On Mar 30, 2:59 pm, Stevo <n...@mail.invalid> wrote:
>
>
>
> > Alan Gutierrez wrote:
> > > I'm wondering how I check for a missing argument. I'm creating a
> > > jQuery extension, so maybe there is a best practice specific to
> > > jQuery.
>
> > > function foo( data, type ) {
> > > if ( type == null ) type = "text"
> > > bar( data, type )
> > > }
>
> > > Should I be testing for null or undefined?
>
> > > Alan Gutierrez
>
Please don't quote signatures.
> > I wouldn't use the name type, but assuming the name type is OK, then
> > if(type==undefined) will work. You could also check arguments.length
>
> I'd go with checking Arguments.length.
And all known agents will dutifully throw an exception.
Jorge
> I'm wondering how I check for a missing argument. (...)
>
> function foo( data, type ) {
>
> Should I be testing for null or undefined?
None. Just write: type= type || "text";
If type is missing or "falsy" (null, undefined, 0, false or "") it
will become "text".
Using arguments slows down execution and will throw an error (IIRC) in
ECMAScript 5 "strict".
--
Jorge.
Jorge
>
> arguments (...) will throw an error (IIRC) in ECMAScript 5 "strict".
Forget that nonsense ^^^^^^. Sorry :-)
--
Jorge.
Stevo
I was going to suggest that, but he didn't want falsy, just undefined.
For example 0 or "" might be acceptable inputs.
Gregor Kofler
If explicitly checking for undefined I'd recommend using
typeof yourVar == "undefined"
since undefined can be set to any value and type == undefined can give
"unexpected" results. In the OPs example
if(!type) {type = "text"} is perhaps sufficient.
Gregor
--
http://www.gregorkofler.com
http://web.gregorkofler.com - vxJS, a JS lib in progress
Jorge
>
> I was going to suggest that, but he didn't want falsy, just undefined.
> For example 0 or "" might be acceptable inputs.
Looks like if "type" was a string... but who knows.
--
Jorge.
kangax
> On Mar 30, 8:49 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>> I'm wondering how I check for a missing argument. (...)
>>
>> function foo( data, type ) {
>> if ( type == null ) type = "text" (...)
>>
>> Should I be testing for null or undefined?
>
> None. Just write: type= type || "text";
>
> If type is missing or "falsy" (null, undefined, 0, false or "") it
and `NaN`
> will become "text".
> Using arguments slows down execution and will throw an error (IIRC) in
> ECMAScript 5 "strict".
That's not true.
First of all, there's no ECMAScript 5 (to my knowledge). Second,
ECMAScript 3.1 Draft (which I assume you had in mind) defines `callee`
and `caller` properties of an `arguments` object as throwing TypeError
on access (and only in strict mode).
Nothing is thrown when `arguments` object itself is being accessed.
--
kangax
David Mark
> Jorge wrote:
> > On Mar 30, 8:49 pm, Alan Gutierrez <a...@blogometer.com> wrote:
> >> I'm wondering how I check for a missing argument. (...)
>
> >> function foo( data, type ) {
> >> if ( type == null ) type = "text" (...)
>
> >> Should I be testing for null or undefined?
>
> > None. Just write: type= type || "text";
>
> > If type is missing or "falsy" (null, undefined, 0, false or "") it
>
> and `NaN`
>
> > will become "text".
> > Using arguments slows down execution and will throw an error (IIRC) in
> > ECMAScript 5 "strict".
>
> That's not true.
>
> First of all, there's no ECMAScript 5 (to my knowledge).
Opinion appears divided on the subject. "Jorge" says there is,
everyone else says there isn't. Given his recent tightrope walk with
lucidity, his claim should be dismissed out of hand.
[snip]
Thomas Allen
Give the guy a break. He already admitted that he was incorrect:
> Forget that nonsense ^^^^^^. Sorry :-)
Thomas
David Mark
I didn't write that you pugnacious little pissant. Learn to quote or
go back to jQuery-land. Sheesh.
Looking back at the previous posts, "Jorge" wrote the above line and
it did *not* refer to his delusions about "ECMAScript 5."
Garrett Smith
> I'm wondering how I check for a missing argument.
Check arguments.length;
I'm creating a
> jQuery extension, so maybe there is a best practice specific to
> jQuery.
>
>
> function foo( data, type ) {
> if ( type == null ) type = "text"
> bar( data, type )
> }
>
> Should I be testing for null or undefined?
You could test for either, but == isn't going to differentiate between
the two.
null == undefined
- was posted within the last two days.
>
> Alan Gutierrez
Garrett
Alan Gutierrez
Actually, I figured out that I'm testing for a specific value for
type, so I don't need to worry about the absence of the value, I don't
think.
function foo( data, kindOfData ) {
if ( kindOfData == "xml" ) {
// If the data kind is xml, baz the data.
// If the data kind is null or undefined, this will be skipped.
data = baz( data );
}
bar( data, kindOfData );
}
So, Jorge's example made me rethink. Thanks for everyone's help on
varargs.
Alan Gutierrez
Thomas Allen
Hi David,
You seem to be a very negative, mean-spirited individual. I sincerely
hope that things look up for you, at the very least so that you don't
drive away more well-intentioned individuals with imperfect knowledge.
Enjoy your mailing list. But it would be irresponsible of me to not
report this to the list's owner as abuse, so I will do so.
Thomas
David Mark
Hi. How are you?
>
> You seem to be a very negative, mean-spirited individual. I sincerely
I am truly sorry you feel that way.
> hope that things look up for you, at the very least so that you don't
> drive away more well-intentioned individuals with imperfect knowledge.
Cue the violins.
> Enjoy your mailing list.
Glad you feel that way, despite the misconceptions.
> But it would be irresponsible of me to not
> report this to the list's owner as abuse, so I will do so.
>
So you are going to report me to myself?
As with your destructive jQuery habit, I will try to save you some
time here. It's not a list, I don't own it and neither does anyone
else.
Tim Streater
<80fff749-f8ec-4a3c...@q9g2000yqc.googlegroups.com>,
Thomas Allen <thomas...@gmail.com> wrote:
> You seem to be a very negative, mean-spirited individual. I sincerely
> hope that things look up for you, at the very least so that you don't
> drive away more well-intentioned individuals with imperfect knowledge.
> Enjoy your mailing list. But it would be irresponsible of me to not
> report this to the list's owner as abuse, so I will do so.
Which mailing list are you talking about?
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
Jorge
LOL. "tightrope walk with lucidity" :-)
https://mail.mozilla.org/pipermail/es-discuss/2009-March/009111.html
--
Jorge.
David Mark
Even if that guy is not a crackpot, your recent babbling streak
spanned more than this topic.
Thomas Allen
Just re-joined for one last message because, frankly, this is
priceless:
http://www.reddit.com/r/programming/comments/7vul9/some_technical_criticism_of_jquery_code/
Apparently I'm not alone. I had a twilight zone moment there my code
seemed like utter shite because I was taking David Mark seriously.
Good to know he's just a pretentious turd with limited credentials :^)
Anyway, good luck DUDE (since it seems that ticks you off).
Thomas
David Mark
> On Mar 30, 6:47 pm, Jorge <jo...@jorgechamorro.com> wrote:
>
>
>
> > On Mar 30, 10:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > On Mar 30, 4:04 pm, kangax <kan...@gmail.com> wrote:
>
> > > > First of all, there's no ECMAScript 5 (to my knowledge).
>
> > > Opinion appears divided on the subject. "Jorge" says there is,
> > > everyone else says there isn't. Given his recent tightrope walk with
> > > lucidity, his claim should be dismissed out of hand.
>
> > LOL. "tightrope walk with lucidity" :-)
>
> >https://mail.mozilla.org/pipermail/es-discuss/2009-March/009111.html
>
> > --
> > Jorge.
>
> Just re-joined for one last message because, frankly, this is
> priceless:
http://www.reddit.com/r/programming/comments/7vul9/some_technical_cri...
Joe Six-Pack late for the ball again.
>
> Apparently I'm not alone.
No. Not by a long shot.
> I had a twilight zone moment there my code
> seemed like utter shite because I was taking David Mark seriously.
No, you had a brief moment of clarity that was apparently interrupted
by something you thought you saw on Reddit. I see that evem after
your visit, the link to the jQuery review has more up votes than
down. :)
Perhaps you mean the pro-jQuery commentators who attempted a
filibuster? In any event, that is old news and originally published
here (again, you could have saved some time.)
> Good to know
There you go.
[snip]
Jon Gómez
Thomas Allen, quoting Jorge, wrote,
>> Forget that nonsense ^^^^^^. Sorry :-)
David Mark in response wrote,
> I didn't write that you pugnacious little pissant. Learn to quote or
> go back to jQuery-land. Sheesh.
The "forget that nonsense" text wasn't properly quoted--that is true.
However, it seemed pretty clear to me from context that Thomas was
referring to Jorge's post.
He is responding to negative statements about Jorge, and that seems to
be the referent of "the guy" he is asking us to give a break. So the
"he" to whom Thomas attributes the "forget" text is pointing to its
antecedent, "the guy", who must be Jorge.
So Thomas didn't want to make David look bad. He wasn't being
intentionally aggressive, i.e., pugnacious--he was just imprecise to the
point of error.
I was already cutting Jorge slack. Regardless, I appreciate the
underlying sentiment of Thomas' post. Those who feel otherwise, very
well, everyone as they wish.
Jon.
Jon Gómez
[...]
> Anyway, good luck DUDE (since it seems that ticks you off).
Well, now that is fractious. :(
Jon.
David Mark
> Thomas Allen, quoting Jorge, wrote,
>
> >> Forget that nonsense ^^^^^^. Sorry :-)
>
> David Mark in response wrote,
>
> > I didn't write that you pugnacious little pissant. Learn to quote or
> > go back to jQuery-land. Sheesh.
>
> The "forget that nonsense" text wasn't properly quoted--that is true.
> However, it seemed pretty clear to me from context that Thomas was
> referring to Jorge's post.
>
> He is responding to negative statements about Jorge, and that seems to
> be the referent of "the guy" he is asking us to give a break. So the
> "he" to whom Thomas attributes the "forget" text is pointing to its
> antecedent, "the guy", who must be Jorge.
>
> So Thomas didn't want to make David look bad. He wasn't being
> intentionally aggressive, i.e., pugnacious--he was just imprecise to the
> point of error.
LOL. You aren't familiar with his larger body of work.
[snip]
Richard Cornford
> On Mar 30, 6:47 pm, Jorge wrote:
>> On Mar 30, 10:19 pm, David Mark wrote:
<snip>
>>> Opinion appears divided on the subject. "Jorge" says there is,
>>> everyone else says there isn't. Given his recent tightrope walk
>>> with lucidity, his claim should be dismissed out of hand.
>>
>> LOL. "tightrope walk with lucidity" :-)
>>
>> https://mail.mozilla.org/pipermail/es-discuss/2009-March/009111.html
> Just re-joined for one last message because, frankly, this
> is priceless:
> http://www.reddit.com/r/programming/comments/7vul9/some_technical_criticism_of_jquery_code/
>
> Apparently I'm not alone. I had a twilight zone moment there my code
> seemed like utter shite because I was taking David Mark seriously.
> Good to know he's just a pretentious turd with limited credentials :^)
Remember that when someone does not know enough about the subject to
apply any informed judgment, while suffering an unrealistic
overconfidence in their own abilities in the filed, they are likely do
jump to all sorts of conclusions about an interlocutor who disagrees
with them.
A similarly misguided reaction to David's criticisms of JQuery can be
found here:-
<URL: http://groups.google.com/group/jquery-dev/msg/69f2b44340d42648 >
But having read that take a step back and look at the contents of the
thread that contains that post. Particularly observe that the vast
majority of the code that David criticised at the time is no longer in
JQuery, indeed his primary criticism at that time cantered around the
use of user agent string based browser detection, which has now been
completely removed from JQuery as of version 1.3. That alone makes a
significant point, perhaps a point about who is following and who is
leading.
Perspectives differ.
Richard.
David Mark
wrote:
> Thomas Allen wrote:
> > On Mar 30, 6:47 pm, Jorge wrote:
> >> On Mar 30, 10:19 pm, David Mark wrote:
> <snip>
> >>> Opinion appears divided on the subject. "Jorge" says there is,
> >>> everyone else says there isn't. Given his recent tightrope walk
> >>> with lucidity, his claim should be dismissed out of hand.
>
> >> LOL. "tightrope walk with lucidity" :-)
>
> >>https://mail.mozilla.org/pipermail/es-discuss/2009-March/009111.html
> <snip>
> > Just re-joined for one last message because, frankly, this
> > is priceless:
>
> > Apparently I'm not alone. I had a twilight zone moment there my code
> > seemed like utter shite because I was taking David Mark seriously.
> > Good to know he's just a pretentious turd with limited credentials :^)
>
> <snip>
>
> Remember that when someone does not know enough about the subject to
> apply any informed judgment, while suffering an unrealistic
> overconfidence in their own abilities in the filed, they are likely do
> jump to all sorts of conclusions about an interlocutor who disagrees
> with them.
>
> A similarly misguided reaction to David's criticisms of JQuery can be
> found here:-
>
> <URL:http://groups.google.com/group/jquery-dev/msg/69f2b44340d42648>
>
> But having read that take a step back and look at the contents of the
> thread that contains that post. Particularly observe that the vast
> majority of the code that David criticised at the time is no longer in
> JQuery, indeed his primary criticism at that time cantered around the
> use of user agent string based browser detection, which has now been
> completely removed from JQuery as of version 1.3. That alone makes a
> significant point, perhaps a point about who is following and who is
> leading.
Another point was the attribute/property mix-up. I think Resig's only
comment at the time was that the "attr" method "could use a rewrite."
Hard to believe that the new version hasn't improved a whit (other
than to remove the browser sniffing.) Of course, the documentation
has the same identity crisis as the code, so it is hard to say what
Resig imagines this method does.
As it is called "attr" and the most used path calls get/setAttribute
and the first argument is an attribute name, I think it is fair to say
he was trying to smooth out differences between the standards and IE's
broken as designed renditions, which debuted before the turn of the
century. As of today, his effort is a complete failure.
Obviously it was lost on him that most applications do not need those
methods at all. As noted, the results are farcically confusing,
inconsistent and occasionally illegal. Thrown exceptions should be an
expected behavior (certainly in 1.2x.)
As written, the code is liable to pass virtually anything to get/
setAttribute (incorrect attribute names, bad values), or may veer off
and get/set a property instead. The behavior varies wildly between
1.2x and 1.3x (as well as between browsers) and it is perhaps the most
used method in jQuery (after - each - probably.)
I suspect that projects like jQuery get away with such inept efforts
as the users of these tools are preconditioned to blame everything on
browser quirks. They are sure that cross-browser scripting is Mission
Impossible and jQuery reinforces their poor image of Javascript and
DOM implementations by making everything painfully complicated and
inconsistent. The dev group doesn't make anything look easy.
>
> Perspectives differ.
>
Yeah. jQuery's site starts out:
"jQuery is a fast and concise JavaScript Library that simplifies..."
We know that, relatively speaking, it isn't fast at anything. I don't
know what a "concise library" is, but that doesn't sound like jQuery
either. Doesn't simplify anything from what I can see. Community
seems clueless about the code they use, documentation is confused and
the author can't seem to stop demonstrating his ignorance in public.
What was the selling point again?
Richard Cornford
> On Mar 30, 8:58 pm, Richard Cornford wrote:
<snip>
>> A similarly misguided reaction to David's criticisms of JQuery
>> can be found here:-
>>
>> <URL:http://groups.google.com/group/jquery-dev/msg/69f2b44340d42648>
>>
>> But having read that take a step back and look at the contents
>> of the thread that contains that post. Particularly observe that
>> the vast majority of the code that David criticised at the time
>> is no longer in JQuery, indeed his primary criticism at that time
>> cantered around the use of user agent string based browser
Should have been "centred" (though maybe not s funny).
>> detection, which has now been completely removed from JQuery as of
>> version 1.3. That alone makes a significant point, perhaps a point
>> about who is following and who is leading.
>
> Another point was the attribute/property mix-up. I think Resig's
> only comment at the time was that the "attr" method "could use a
> rewrite."
My recollection is that Resig did not explain/justify any of criticised
code, beyond implying that he knew what heat he was doing, and then
rapidly descending to the nonsensical position that nobody who had not
created their own general-purpose javascript library was qualified to
criticise his code.
> Hard to believe that the new version hasn't improved a whit (other
> than to remove the browser sniffing.)
<snip>
There have been more internal improvements than just that. Those bloody
silly isFunction and isArray methods are much changed, and some of the
method overloading has been taken down a notch so that it is more in
line with what realistically can be achieved in javascript.(and
re-documented so that it no longer asserts an ability to do the
impossible). There is even a move towards modularising the internal
structure, with the selector engine becoming a discrete component.
Of course the public API is still largely set in concrete, and likely to
stay that way, which pretty much precludes entire categories of initial
design mistakes ever being addressed. The dilemma of not wanting to pull
the rug out from under the feet of the people already using it. But
since in reality libraries do get releases in new versions that are not
back-compatible with previous versions there are opportunities at those
points do a major re-working of the API/general structure, though kangax
came close to expressing an alternative issue with doing that in:-
<URL: http://groups.google.com/group/prototype-core/msg/3904f48e1774cc75
>
- where he wrote; "It's not clear what will be left of Prototype if it
was to change its
core way of doing things - ... ". That issue being the library's
identity; if you have been marketing an identity how far can things be
changed before its existing users start taking offence? Lasse may
suggest that these things will 'win' in the long run, but if they change
out of recognition before they 'win' would they have won at all?
>> Perspectives differ.
>
> Yeah. jQuery's site starts out:
>
> "jQuery is a fast and concise JavaScript Library that simplifies..."
>
> We know that, relatively speaking, it isn't fast at anything.
It does seem that all the relative speed testing is carried out against
other general-purpose libraries. And against that benchmark 'concise'
comes down in JQuery's favour (for the time being). There doesn't seem
much interest in doing the comparisons on an absolute basis.
> I don't know what a "concise library" is, but that doesn't
> sound like jQuery either.
Presumably it is supposed to be short/small. But it is probably best to
regard the whole thing as pure marketing-speak.
> Doesn't simplify anything from what I can see.
Yes, I often read people promoting JQuery as 'whatever' and end up
thinking what on earth where you doing before that makes *this* look
simple, intuitive, intelligible, easy to maintain/debug, etc.?
> Community seems clueless about the code they use,
An observation on these 'communities'; on:-
<URL: http://groups.google.com/group/jquery-en/ >
- what proportion of questions asked receive no answer at all? I make it
more than 25%; more than 1 in 4.
> documentation is
> confused and the author can't seem to stop demonstrating his
> ignorance in public. What was the selling point again?
Full money back guarantee if not completely satisfied (excluding
merchandising)?
Richard.
Jorge
wrote:
> Thomas Allen wrote:
> > On Mar 30, 6:47 pm, Jorge wrote:
> >> On Mar 30, 10:19 pm, David Mark wrote:
> <snip>
> >>> Opinion appears divided on the subject. "Jorge" says there is,
> >>> everyone else says there isn't. Given his recent tightrope walk
> >>> with lucidity, his claim should be dismissed out of hand.
>
> >> LOL. "tightrope walk with lucidity" :-)
>
> >>https://mail.mozilla.org/pipermail/es-discuss/2009-March/009111.html
> <snip>
> > Just re-joined for one last message because, frankly, this
> > is priceless:
>
> > Apparently I'm not alone. I had a twilight zone moment there my code
> > seemed like utter shite because I was taking David Mark seriously.
> > Good to know he's just a pretentious turd with limited credentials :^)
>
> <snip>
>
> Remember that when someone does not know enough about the subject to
> apply any informed judgment, while suffering an unrealistic
> overconfidence in their own abilities in the filed, they are likely do
> jump to all sorts of conclusions about an interlocutor who disagrees
> with them.
I'm seeing what you've (purposedly) quoted, Cornford, and you're an
idiot, puto inglesito de mierda.
--
Jorge.
Lasse Reichstein Nielsen
> On Mar 30, 3:12 pm, Thomas Allen <thomasmal...@gmail.com> wrote:
>> I'd go with checking Arguments.length.
>
> And all known agents will dutifully throw an exception.
... because "arguments" shouldn't be capitalized.
Oh, do try to be a little helpful, instead of wasting time on typos.
Anyway, I wouldn't use "arguments.length", because it makes the
Javascript engine need to create the arguments object. Depending
on how often the function is called, it can be a significant overhead.
Actually, I'd only use arguments.length if there is a variable number
of arguments, or if it should make a difference whether the user
passed "undefined" as an argument, or omitted the argument (which it
shouldn't ever do!).
For something like this, I'd just us
if (type === null) { type = "text"; }
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
David Mark
wrote:
> David Mark <dmark.cins...@gmail.com> writes:
> > On Mar 30, 3:12 pm, Thomas Allen <thomasmal...@gmail.com> wrote:
> >> I'd go with checking Arguments.length.
>
> > And all known agents will dutifully throw an exception.
>
> ... because "arguments" shouldn't be capitalized.
> Oh, do try to be a little helpful, instead of wasting time on typos.
>
I doubt that was a typo. Read his other posts from yesterday. And
everybody else knows what the mistake is. Mind your own time.
[snip]
>
> /L
> --
> Lasse Reichstein Holst Nielsen
> 'Javascript frameworks is a disruptive technology'
^^^^^^^^^^
You misspelled "destructive." Try to pay attention.
Dr J R Stockton
g2000pre.googlegroups.com>, Mon, 30 Mar 2009 11:49:54, Alan Gutierrez
<al...@blogometer.com> posted:
>I'm wondering how I check for a missing argument.
Only you can tell that. It would be better to wonder how you should
check for a missing argument.
Testing in FF 3.0.7 & IE 7 :
One cannot have a hole in the arguments list of a function call (that's
a syntax error); missing arguments will be at the end. Therefore,
consulting arguments.length will tell you which arguments are
missing.
Within the routine, a missing argument is not missing, but has the type
and value of undefined . However, an argument which is present in the
call, but is undefined, also has that value internally.
Some, but few, functions do anything useful with an argument of more
than one type. Therefore, you can often do better by testing whether an
argument of the required type is present at that position. That will
restrict the use of automatic type conversion, requiring sometimes
conversion before or within the argument list - that might be considered
to be advantageous for legibility. But a function such as pad-to-length
ought to be able to pad any type or value that might be presented, even
if that type or value is an error.
I find the following to be successful (it makes the test brief) :
function F(A, B) { var U
if (B==U) alert ("Wot no B!")
/* ... */ }
Use something like this to test, in a textarea with eval :
function ff(a, b, c) {
return [arguments.length, " -- ", a, b, c, typeof c, " + ", b+c] }
var U
ff(1, 2) + " " + ff(1, 2, U, 4)
--
(c) John Stockton, nr London UK. replyYYWW merlyn demon co uk Turnpike 6.05.
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes precede replies. Snip well. Write clearly. Mail no News.
David Mark
wrote:
> David Mark wrote:
> > On Mar 30, 8:58 pm, Richard Cornford wrote:
> <snip>
> >> A similarly misguided reaction to David's criticisms of JQuery
> >> can be found here:-
>
> >> <URL:http://groups.google.com/group/jquery-dev/msg/69f2b44340d42648>
>
> >> But having read that take a step back and look at the contents
> >> of the thread that contains that post. Particularly observe that
> >> the vast majority of the code that David criticised at the time
> >> is no longer in JQuery, indeed his primary criticism at that time
> >> cantered around the use of user agent string based browser
>
> ^^^^^^^^
> Should have been "centred" (though maybe not s funny).
>
> >> detection, which has now been completely removed from JQuery as of
> >> version 1.3. That alone makes a significant point, perhaps a point
> >> about who is following and who is leading.
>
> > Another point was the attribute/property mix-up. I think Resig's
> > only comment at the time was that the "attr" method "could use a
> > rewrite."
>
> My recollection is that Resig did not explain/justify any of criticised
> code, beyond implying that he knew what heat he was doing, and then
> rapidly descending to the nonsensical position that nobody who had not
> created their own general-purpose javascript library was qualified to
> criticise his code.
How interesting for the thousands of sites that deployed jQuery 1.2x
in the last year. Resig was busy putting up (and immediately taking
down) rock star Websites, instead of cleaning up his mess. He waits
until IE8 is upon us to release a new version that might not fall on
its face in the default mode (and is apparently unsupported in other
modes.)
And yeah, their arguments always devolve to things like:
1. Why aren't you helping out? Where's your library?
2. As if Web developers could do better (of course they could, by
avoiding browser scripting until they are ready.)
And as is patently obvious, Resig and his buddies tried to make jQuery
look more like My Library. Three years of bumbling and in the end the
solution is to copy from me. You know, not a thank you from any of
them (just more shrill whining and insults.)
>
> > Hard to believe that the new version hasn't improved a whit (other
> > than to remove the browser sniffing.)
>
> <snip>
>
> There have been more internal improvements than just that. Those bloody
> silly isFunction and isArray methods are much changed, and some of the
> method overloading has been taken down a notch so that it is more in
> line with what realistically can be achieved in javascript.(and
> re-documented so that it no longer asserts an ability to do the
> impossible). There is even a move towards modularising the internal
> structure, with the selector engine becoming a discrete component.
I was referring only to the attr method (though - each - qualifies as
well.) The former is clearly a disaster and has barely been touched
in 1.3x. We know about the latter.
>
> Of course the public API is still largely set in concrete, and likely to
> stay that way, which pretty much precludes entire categories of initial
> design mistakes ever being addressed. The dilemma of not wanting to pull
> the rug out from under the feet of the people already using it. But
> since in reality libraries do get releases in new versions that are not
> back-compatible with previous versions there are opportunities at those
> points do a major re-working of the API/general structure, though kangax
> came close to expressing an alternative issue with doing that in:-
>
> <URL:http://groups.google.com/group/prototype-core/msg/3904f48e1774cc75
> >
>
> - where he wrote; "It's not clear what will be left of Prototype if it
> was to change its
> core way of doing things - ... ". That issue being the library's
> identity; if you have been marketing an identity how far can things be
> changed before its existing users start taking offence? Lasse may
> suggest that these things will 'win' in the long run, but if they change
> out of recognition before they 'win' would they have won at all?
I don't think they will win in any form. They are creating a vacuum
for something much better to fill (just don't know what it is yet.)
>
> >> Perspectives differ.
>
> > Yeah. jQuery's site starts out:
>
> > "jQuery is a fast and concise JavaScript Library that simplifies..."
>
> > We know that, relatively speaking, it isn't fast at anything.
>
> It does seem that all the relative speed testing is carried out against
> other general-purpose libraries. And against that benchmark 'concise'
> comes down in JQuery's favour (for the time being). There doesn't seem
> much interest in doing the comparisons on an absolute basis.
>
> > I don't know what a "concise library" is, but that doesn't
> > sound like jQuery either.
>
> Presumably it is supposed to be short/small. But it is probably best to
> regard the whole thing as pure marketing-speak.
Certainly. It is along the lines of "it just works", "do more with
less", etc.
>
> > Doesn't simplify anything from what I can see.
>
> Yes, I often read people promoting JQuery as 'whatever' and end up
> thinking what on earth where you doing before that makes *this* look
> simple, intuitive, intelligible, easy to maintain/debug, etc.?
In most cases they weren't doing anything before, so they have nothing
to compare it to. It's a bandwagon effect (so many others are doing
it, it must be good!)
>
> > Community seems clueless about the code they use,
>
> An observation on these 'communities'; on:-
>
> <URL:http://groups.google.com/group/jquery-en/>
>
> - what proport1ion of questions asked receive no answer at all? I make it
> more than 25%; more than 1 in 4.
And how many of those are accurate answers?
>
> > documentation is
> > confused and the author can't seem to stop demonstrating his
> > ignorance in public. What was the selling point again?
>
> Full money back guarantee if not completely satisfied (excluding
> merchandising)?
Yeah, good luck returning the books. I suppose they could be used to
line bird cages, start fires, etc.
Matt Kruse
> Another point was the attribute/property mix-up. I think Resig's only
> comment at the time was that the "attr" method "could use a rewrite."
I'd like to see some specific test cases where the attr() method
fails. I'm sure they exist, but I'm not personally interested enough
to hunt them down. I never use attr(). But with some failing test
cases, I think an attr() re-write might get some attention.
> Hard to believe that the new version hasn't improved a whit (other
> than to remove the browser sniffing.)
There are other improvements, as Richard points out. Change is slow,
especially in collaborative efforts. At least they are moving in the
right direction, even if it's slow and not quite straight.
> "jQuery is a fast and concise JavaScript Library that simplifies..."
> We know that, relatively speaking, it isn't fast at anything. I don't
> know what a "concise library" is, but that doesn't sound like jQuery
> either. Doesn't simplify anything from what I can see.
I do think it simplifies many things.
The use of CSS selectors to create a group of elements to operate on
is very handy, and the main draw of jQuery and similar libs. I know
it's possible to use other stand-alone selector libraries, but if it's
built into jQuery and jQuery has a large and growing userbase, why not
just use it?
I also find some of its manipulation handy - slideUp(), fadeOut(),
etc. Although quirky in IE6 (at least), it does what I personally need
it to do, and very easily for me.
The AJAX functionality, while imperfect under the covers, works well
for what I need it to. I like being able to do $('.content
div.description').load(url). It's handy, and it does simplify things.
Matt Kruse
Matt Kruse
> And as is patently obvious, Resig and his buddies tried to make jQuery
> look more like My Library. Three years of bumbling and in the end the
> solution is to copy from me. You know, not a thank you from any of
> them (just more shrill whining and insults.)
"You're so vain. You probably think this library's about you."
Matt Kruse
David Mark
> On Mar 30, 9:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Another point was the attribute/property mix-up. I think Resig's only
> > comment at the time was that the "attr" method "could use a rewrite."
>
> I'd like to see some specific test cases where the attr() method
> fails. I'm sure they exist, but I'm not personally interested enough
> to hunt them down. I never use attr(). But with some failing test
> cases, I think an attr() re-write might get some attention.
I suggest you read this thread again. I'd like to hear your concept
of what that method is *supposed* to do in the first place. The first
argument in a set operation is obviously supposed to be an attribute
name. The second is anyone's guess.
Whatever it is, it goes about it in an inconceivable manner and the
results are predictably inconsistent across jQuery versions, as well
as browsers.
It can't be lost on you that IE8 fixed get/setAttribute, yet this
jQuery abomination is still trying to use a "black list" to determine
when to use DOM properties instead. And, of course, everyone who
hasn't upgraded is stuck with browser sniffing in that function, most
of which makes inferences about *IE*.
Barring that, I suggest you look at the code again. It is only a
couple of dozen lines and the mistakes are obvious (at least for
anyone who has used get/setAttribute in the last ten years.)
The reason you persist in your misconceptions is that you are lucky
enough to have rearranged code that has been demonstrated to work in a
handful of environments and those are the only environments you test
(what a happy coincidence!) Now, the poor slob that comes after you
will be in a world of shit if they need to venture outside of your
comfort zone. How would they even understand your code if you don't?
Obviously you know nothing about the attr method, yet you rely on it
for everything and recommend for others to follow suit.
Seriously, in six paragraphs or less, what does the jQuery attr method
do?
>
> > Hard to believe that the new version hasn't improved a whit (other
> > than to remove the browser sniffing.)
>
> There are other improvements, as Richard points out. Change is slow,
> especially in collaborative efforts. At least they are moving in the
> right direction, even if it's slow and not quite straight.
Like a broken record that goes on forever.
[snip]
David Mark
Hmmm. John Resig publishes a library. I personally explain to him
exactly where he fouled up (at least in part), publish examples of how
to do it right and a year later code shows up in jQuery that is
obviously influenced by mine (right down to the variable names.)
That's reality, not vanity.
David Mark
> On Mar 31, 5:09 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > On Mar 30, 9:19 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > Another point was the attribute/property mix-up. I think Resig's only
> > > comment at the time was that the "attr" method "could use a rewrite."
>
> > I'd like to see some specific test cases where the attr() method
> > fails. I'm sure they exist, but I'm not personally interested enough
> > to hunt them down. I never use attr(). But with some failing test
> > cases, I think an attr() re-write might get some attention.
>
> I suggest you read this thread again. I'd like to hear your concept
Actually, I meant this thread:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/95c4bbfe39f19ce4#
I presume you missed it.
So, assuming you are not up to the task of explaining (in simple
terms) what this lynch-pin method does, I'll try to give you a head
start. You can't fix it if you don't understand what it does (and
what it should be doing.) One could argue that you shouldn't use or
recommend something you don't understand, but we've been over that ad
nauseum. Consider this the final exam for your credibility.
In jQuery, the attr method will do one of the following, depending on
its arguments:
1. Get a DOM property
2. Set a DOM property
3. Get an attribute
4. Set an attribute
The course taken depends on:
1. DOM type (XML or HTML)
2. Element type
3. Browser
4. jQuery version
The first argument is an attribute name, which jQuery might mutate,
depending on:
1. An incomplete list of properties, which changes per version
2. Nothing else.
The second point alludes to the fact that the attr method couldn't
care less about the second argument, which is completely
undocumented. The decision about when to use get/setAttribute or not
(remember the name is already mutated) is unrelated to the "black
list" result, allowing all sorts of invalid names and/or values to
slip through. Get it?
In other words, at a glance, what do these do?
$(el).attr('disabled', 'disabled');
$(el).attr('disabled', true);
As expected, the results vary as described above. Contrast that with:
el.disabled = true;
How about these?
$(el).attr('onclick', 'alert("test")');
$(el).attr('onclick', function() { alert('test'); });
Contrast with:
el.onclick = function() { alert('test'); };
Bonus question, what would this be expected to return?
${el).attr('rowspan');
What about this?
${el).attr('rowSpan');
That's why I'd never read your code (or anything like it.) Confronted
with such illegible nonsense, it is best to throw it away and start
over (losing at least 50K in the process.)
Regardless of any of this, this outrageous over-complication was never
needed. You've got four functions here (getProperty, setProperty,
getAttribute, setAttribute) and two are rarely needed in an HTML DOM.
Resig has mashed them all up into one idiotic function, which can't do
any of them right. He runs this crap through his crystal ball (a
patchwork quilt of unit tests that mirror his meanderings and
misconceptions), pronounces it as "working" and now half the Web is
running on his latest attempt to "pave over" differences in browsers.
So what does "moving in the right direction" mean to... anybody? Do
you mark your calendar to deploy jQuery a year from now, assuming
Resig will figure out his mistakes by then? Are you a glutton for
upgrades? BTW, have *you* even upgraded yet? If not, you best stop
wasting time on futile arguments.
Why would anyone start out in browser scripting trying to learn the
attr method when even the author is clueless about its purpose, as
well as its execution (and there are much simpler and more concise
techniques to be found in Javascript?) Ironic that those who peddle
paranoia about browser differences could be so completely unable to
deal with them.
Anyway, I await your explanation of the attr method and just what
makes it so simple and concise. :)
Matt Kruse
> I suggest you read this thread again.
I'll pass. Better things to do.
> I'd like to hear your concept
> of what that method is *supposed* to do in the first place.
I'm unclear about what exactly it intends to do.
> Obviously you know nothing about the attr method, yet you rely on it
> for everything and recommend for others to follow suit.
I don't use it. I'm pretty sure I said that.
> Seriously, in six paragraphs or less, what does the jQuery attr method
> do?
Set or get DOM properties/node attributes, I presume. Apparently it
doesn't do this well, which is one of the reasons I don't use it. That
and the fact that I have never found a need for it.
> > There are other improvements, as Richard points out. Change is slow,
> > especially in collaborative efforts. At least they are moving in the
> > right direction, even if it's slow and not quite straight.
> Like a broken record that goes on forever.
Pot. Kettle. Blah blah blah.
Matt Kruse
Matt Kruse
> I presume you missed it.
I did. I'll read through it at some point.
> So what does "moving in the right direction" mean to... anybody?
To me it means that jQuery is a major library that is improving, not
getting worse. It removed browser sniffing - something other major
libs haven't even touched. It has improved the amazingly broken
isFunction kind of detection. It has isolated its selector engine and
sped it up. It has fixed some of the junk that was remaining in the
code, based on recommendations and discussions. It's getting better,
not worse. IMO. So I have hope that it will overcome some of the
problems it still has.
> BTW, have *you* even upgraded yet?
No, but I don't use it that much. No need to upgrade something that
isn't broken.
> If not, you best stop
> wasting time on futile arguments.
This has never worked for me in the past ;)
> Anyway, I await your explanation of the attr method and just what
> makes it so simple and concise. :)
I'm sure you do, but I've got more interesting challenges to tackle. I
participate in threads like these to try to get a good idea of what
problems exist and where the solution might lie, and maybe to find a
way to get those things fixed in arguably the most popular js
framework on the web. I'd like to think that the removal of browser
sniffing and some other improvements in jQuery were partly due to my
participation. I don't do the deep analysis, the code fixing, or the
testing, but I can help the process along where possible. But I'm not
going to spend lots of time analyzing and trying to explain code.
There are better uses of my time.
Matt Kruse
David Mark
> On Mar 31, 4:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I suggest you read this thread again.
>
> I'll pass. Better things to do.
But you said:
"I'd like to see some specific test cases where the attr() method
fails."
You also said something about a rewrite. Of course, a rewrite of this
would likely break a lot of apps, plug-ins, Websites, etc.
>
> > I'd like to hear your concept
> > of what that method is *supposed* to do in the first place.
>
> I'm unclear about what exactly it intends to do.
So you recommend something that you are unclear about. We aren't
talking about some obscure backwater method here. This is what jQuery
developers use to get and set properties on DOM nodes (among other
things.) How can you not know this? It's especially vexing as you
were told this over a year ago. You specifically and you have been
popping up like some indefatible toon to plug jQuery ever since.
Let me make it clear to you. That method is poorly designed and
executed and is completely unnecessary. The method to get a property
is one line. To set is two. You didn't need to invoke the get/
setAttribute methods at all. You certainly didn't need to invoke them
with incorrect names and/or values. What a ridiculous thing to do,
turning the simple and critical task of getting and setting DOM
properties into a series of misadventures that guarantee cross-browser
incompatibility. Hell, as designed it doesn't work properly in *any*
browser.
>
> > Obviously you know nothing about the attr method, yet you rely on it
> > for everything and recommend for others to follow suit.
>
> I don't use it. I'm pretty sure I said that.
So you did. Have to wonder why you would bypass the wonderful
convenience. What do you load lists of elements into his wrappers
for? Regardless, all of the other jQuery "programmers" use it to
death. And, of course, you are using it whether you know it or not as
jQuery itself uses it (in for a penny, in for a pound.)
And you do realize this is but one function. It is just ironic that
it is the very first botched jQuery function I explained to you (and
Resig) and here you are a year and a half later parroting the same old
song and claiming ignorance. I remember quite specifically that you
chimed in about XML documents retrieved via XHR, prompting a warning
that this attr method was hardly suitable for such tasks. It wasn't
then and it still isn't. Resig's fanciful mungineering isn't suitable
for HTML DOM's either.
>
> > Seriously, in six paragraphs or less, what does the jQuery attr method
> > do?
>
> Set or get DOM properties/node attributes, I presume.
Brilliantly put. That's more or less what the documentation says.
Are you sure you want to hand that in?
> Apparently it
> doesn't do this well, which is one of the reasons I don't use it.
Yet you will recommend it. Again, these issues are right up front.
[snip]
Thomas 'PointedEars' Lahn
> David Mark writes:
>> On Mar 30, 3:12 pm, Thomas Allen <thomasmal...@gmail.com> wrote:
>>> I'd go with checking Arguments.length.
>> And all known agents will dutifully throw an exception.
>
> Oh, do try to be a little helpful, instead of wasting time on typos.
However, that guy is notorious for not understanding what he's doing and
thinking otherwise.
> Anyway, I wouldn't use "arguments.length", because it makes the
> Javascript engine need to create the arguments object.
That the arguments object is not created when not used is an unfounded
assumption, or rather wishful thinking on your part in order to support your
argument. The ECMAScript Specification, Edition 3 Final, widely implemented
as opposed to the ES 4+(!) dreaming, says otherwise.
So much for being helpful.
PointedEars
David Mark
> On Mar 31, 6:12 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Actually, I meant this thread:
> >http://groups.google.com/group/comp.lang.javascript/browse_thread/thr...
> > I presume you missed it.
>
> I did. I'll read through it at some point.
Hopefully not with a mouth full of food. :)
>
> > So what does "moving in the right direction" mean to... anybody?
>
> To me it means that jQuery is a major library that is improving, not
There's nothing major about. Improving means nothing to someone
putting up a site *today*. Matter of fact, improving implies defects
and the prospect of imminent upgrades. Those are bad things.
> getting worse. It removed browser sniffing - something other major
I know. Well, they sort of removed browser sniffing.
> libs haven't even touched. It has improved the amazingly broken
You are so colossally ignorant. Is this a competition? Resig is way
late on the feature detection kick anyway. All of the people who put
their faith into pre-epiphany versions are now screwed. Who won?
> isFunction kind of detection. It has isolated its selector engine and
> sped it up.
It was always a tortoise. A big, bloated, unnecessary tortoise.
> It has fixed some of the junk that was remaining in the
> code, based on recommendations and discussions. It's getting better,
Yet nobody thought to check the two most used functions in the script
(attr and each.) Both have huge holes in the latest (?) release,
which is two releases since 1.3. Collaboration indeed. You don't
need an army to be this impotent. It's either the worst software
effort or the greatest chimp act ever.
> not worse. IMO. So I have hope that it will overcome some of the
> problems it still has.
But will anyone care when it does? That's a rhetorical question.
>
> > BTW, have *you* even upgraded yet?
>
> No, but I don't use it that much. No need to upgrade something that
> isn't broken.
LOL. You used to use it all the time in some controlled environment.
What happened? And you fail to grasp that time has broken anything
written with 1.2x. Not that it worked before as it hinged largely on
finding "MSIE" in the UA string. At this time, you can't possibly
call such a script usable. If perchance your previous jQuery output
still appears to work in some limited set of browsers, what makes you
think they aren't as brittle as snowflakes?
>
> > If not, you best stop
> > wasting time on futile arguments.
>
> This has never worked for me in the past ;)
>
> > Anyway, I await your explanation of the attr method and just what
> > makes it so simple and concise. :)
>
> I'm sure you do, but I've got more interesting challenges to tackle. I
What a cop-out.
> participate in threads like these to try to get a good idea of what
> problems exist and where the solution might lie, and maybe to find a
I told you about this problem a year and a half ago in a thread very
much like this one. It's not as if it is a little problem.
> way to get those things fixed in arguably the most popular js
> framework on the web.
Both you and Resig had these answers on a silver platter. You didn't
listen or you didn't understand. I don't know what your deal is now
(apparently you abandoned the "most popular js framework on the web.")
> I'd like to think that the removal of browser
> sniffing and some other improvements in jQuery were partly due to my
> participation.
Yes. I remember it well. I mentioned jQuery was a trainwreck. You
mentioned it wasn't. I mentioned it sniffed browsers incessantly.
You mentioned it didn't. I posted a lot of code and comments. You
ran off to tell John Resig. John Resig mentioned I didn't have
anything to say as I didn't write a cool library like jQuery. I wrote
a much cooler library than jQuery and continued to pressure that moron
to change his code. Finally he did. Some of it resembles my code
now. Most is still a shambles.
And you forgot the stuff about the attributes and properties.
> I don't do the deep analysis, the code fixing, or the
Deep analysis? That method is two dozen lines long and I dissected it
for you once. Who does the "code fixing?" Nobody from what I have
seen.
> testing, but I can help the process along where possible.
Don't break your arm patting yourself on the back. And when did this
become the point of this discussion?
> But I'm not
> going to spend lots of time analyzing and trying to explain code.
> There are better uses of my time.
I didn't ask you to explain code. I asked you to explain, in simple
terms, what the attr method is supposed to do. For a well-documented,
well-supported effort like jQuery, that should be a snap for you or
anyone. Certainly it is crucial to know.
It's a trick question. The thing is so monstrously convoluted and
broken that the only explanation would be very long-winded (see my
initial assessments) and prove beyond a shadow of a doubt that jQuery
does not smooth out differences between browsers (it does the exact
opposite in many cases.) Furthermore, it inhibits understanding of
simple and critical concepts like DOM properties vs. attributes. Even
worse, the API can't really be changed at this point, so it will be
hard to break it up without breaking lots of existing code.
David Mark
> On Mar 31, 4:53 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > I suggest you read this thread again.
>
> I'll pass. Better things to do.
>
> > I'd like to hear your concept
> > of what that method is *supposed* to do in the first place.
>
> I'm unclear about what exactly it intends to do.
>
> > Obviously you know nothing about the attr method, yet you rely on it
> > for everything and recommend for others to follow suit.
>
> I don't use it. I'm pretty sure I said that.
>
> > Seriously, in six paragraphs or less, what does the jQuery attr method
> > do?
>
> Set or get DOM properties/node attributes, I presume. Apparently it
> doesn't do this well, which is one of the reasons I don't use it. That
> and the fact that I have never found a need for it.
>
Very interesting.
http://markmail.org/message/ldgy4rawlddcisyy
It starts out:
"I took a look at the 'attr' function today and here are my comments."
So you have gone over this code, apparently in response to my
criticism posted in the fall of 2007. Unfortunately, your analysis
was myopic in that it focused only on the browser sniffing. Again, we
are not talking about an expansive piece of code. So, your claims of
helping this effort aren't confidence inducing.
Here's part of one of the responses, which defended the browser
sniffing:
"This one is easy to answer: consistent behaviour. Suppose I develop
in Firefox, only to find out during testing that it doesn't work in
IE. Due to the nature of this feature, I might have to redesign my
approach to the problem. Lots of lost time, for the dubious gain that
it works for no-IE use cases. If it cannot be made to work at one
place, it should fail everywhere. A consistency layer is not only
about emulating missing or broken functionality."
So other collaborators were inspecting this function back then as
well. Unfortunately, they were prone to techno-babble, rather than
debate.
Another threw in an anecdote about Sun Microsystems:
"Case study: Sun Microsystems de-facto in-house browser is Firefox.
Almost 100% of Sun employees have Firefox and use it as their primary
browser from what I hear."
Resig himself chimed in with this:
"I posted the following reply to comp.lang.javascript:"
Yeah, that was it. Just a self-congratulatory regurgitation of his
post to this group, which didn't address any problems, but did reveal
his inability to read for comprehension. IIRC, he quoted the typeof
xyz == 'array' blunder, but didn't seem to consider it a problem.
There was this endorsement from a clearly disturbed "XML centric"
developer. Gut-wrenching considering the topic at hand.
"I choose jQuery over other javascript libraries because of it's
ability to perform, the clarity of the docs, the talented community,
and most of all for it's elegance. I am an XML centric developer and
have always found the different treatment of 'The DOM' and 'any other
xml' very frustrating."
A vote of confidence:
"John I don't think I have smiled so much throughout such a long
thread in a very long time. Thanks for that. I know it must have been
tiring to justify (so well) all the reasons you have. Hopefully people
like the original complainer will just back off and leave ya alone for
a bit. You should post the replies to this somewhere on a blog so you
can refer back to it whenever someone complains like that again."
Oh brother. Don't think Resig will be posting *that* to a blog any
time soon. :)
This is clearly your "elegant" workaround for attr:
"Not stuck, just need to step out of jQuery for a ms. $('input#pwd')
[0].type = 'text';"
Another vote for browser sniffing:
"Feature-detect fails when a browser implements a feature, but
incorrectly. As a result, browser-specific workarounds are sometimes
necessary. Case closed.
Sent from my iPhone"
Send it back. I'll leave you with this self-referential time-wasting:
"Overall, I have to say I'm really impressed with the jQuery
Development team and the rest of us on the discussion list (if I can
say that in a way without complimenting myself). This thread had all
the right energy to snowball into a flame war / pissing contest and I
think you all have done a good job of keeping yourselves logical and
supportive."
And still completely in the dark. Good night.
David Mark
I've already observed that culture. Interesting that on searching for
"attr(" and "jQuery" on Google, I stumbled across this on an IBM site:
http://www.ibm.com/developerworks/web/library/wa-jquery2/
On section waxes poetically about jQuery and attributes (or so the
author seems to think.)
"Before diving into these methods, let's look at what information
could be stored in page elements. Something as simple as a <p> may
only contain a CLASS or ID as information. Something like an <img> may
contain far more information, things like the "src", the "alt", the
"width", and the "height". Finally, something as complex as an <input
type="password"> may contain things like "defaultValue", "maxLength",
"readOnly", or "accessKey".
This diversity of potential variables has caused jQuery to create a
generalized function to access them. This function is the attr(name)
and is the generic way to access information from any page element.
Take a look at some examples to see how this works."
<img src="/images/space.gif" id="spacer" class="a b c" alt="blank">
// Calls to the attr() function will return the following
$("#spacer").attr("src"); // will return "/images/space.gif"
$("#spacer").attr("alt"); // will return "blank"
// Similarly, you can access the ID in the same way
$(img).each(function(){
$(this).attr("id"); // will return "spacer"
});
That last one is particularly insane.
// will change the maxLength on all password fields to 10 characters
$(":password").attr("maxLength", "10");
Will it? This one is a poser as it uses a property name for the first
argument and an attribute value for the second (the standard
incongruity is reversed.)
IIRC, the camel-case will bypass Resig's black list and it isn't one
of his "special" names either, so assuming an HTML DOM, attr will
attempt to set the maxLength property to "10." I suppose some agents
will allow that. Apparently the 100% safe and compatible alternative
of setting the property wasn't considered cool enough:
el.maxLength = 10;
Lots of similar articles to be found, all recommending similar
patterns. Most are quite recent and appear to have involved a lot of
work (if not thought.) What are these people taking?
Matt Kruse
> What a cop-out.
Why do you continue to invest so much time in these jQuery flame-wars?
You obviously don't use jQuery, so you shouldn't care about its
quality.
You surely don't recommend it to anyone, so you don't have to worry
about its improvements or roadmap or bug list, etc.
If you think it breaks web sites that you use, then
a) There are an awful lot of worse scripts out there that break sites
and I'd think you'd complain about them
b) Your approach to improving the broken web you use is quite
ineffective
If it just annoys the crap out of you that code exists and is used
that is not perfect or even logically sound, then you must be annoyed
by a _lot_ of things you see. I'd guess that some time spent with a
therapist would be more helpful than hours spent in jQuery
discussions.
And if it really just bugs you to the core that a person like John
Resig could get more attention, more popularity, more accolades, more
following, and more pats on the back than you - even though you view
yourself as far superior and more deserving of the praise - well, get
used to it.
So... what is it? Where does all this anger and annoyance come from?
Why do you continue this jQuery bashing repeatedly? Haven't you made
your point over and over and over? What do you hope to gain? You say
you have no desire to help improve such a flawed library as jQuery,
yet you repeatedly point out its short-comings. Why do you bother?
Matt Kruse
Thomas 'PointedEars' Lahn
> On Apr 1, 3:18 am, David Mark <dmark.cins...@gmail.com> wrote:
>> You are so colossally ignorant.
>> [snip]
>> What a cop-out.
>
> Why do you continue to invest so much time in these jQuery flame-wars?
>
> You obviously don't use jQuery, so you shouldn't care about its
> quality.
However David's style, your logic is flawed.
PointedEars
Matt Kruse
wrote:
> However David's style, your logic is flawed.
How so?
Matt Kruse
Matt Kruse
I'll summarize...
On Apr 1, 2:54 am, David Mark <dmark.cins...@gmail.com> wrote:
> Let me make it clear to you. That method is poorly designed and
> executed and is completely unnecessary.
So?
Matt Kruse
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> However David's style, your logic is flawed.
>
> How so?
The most compelling reason for analyzing and criticizing a piece of software
would be, of course, to provide a basis for a recommendation to others as to
why not to use it, and maybe as to why they should use something else
instead. However, evidently Davids comments and occasional rants did have a
positive effect on the thinking of jQuery developers (and John Resig in
particular).
It is therefore not logical of you to imply that he should better cease
these efforts. If anything, his efforts might be instrumental in changing
jQuery into something that can be truthfully recommended by other
knowledgeable developers one day; a fact that, I imagine, would be
appreciated by you the most.
PointedEars
Matt Kruse
wrote:
> The most compelling reason for analyzing and criticizing a piece of software
> would be, of course, to provide a basis for a recommendation to others as to
> why not to use it, and maybe as to why they should use something else
> instead
I agree. But if that were truly his intention, then he is going about
it the wrong way because it's not working. Insulting those you are
trying to help will not accomplish the goal. Bashing the author of the
"bad" code will not help the cause. Being a jerk in public only makes
people _less_ interested in what he has to say.
Also, he rarely recommends better alternatives that are really helpful
to people. He just criticizes jQuery and points out the flaws. So I
don't think this "compelling reason" is what's behind his actions.
> However, evidently Davids comments and occasional rants did have a
> positive effect on the thinking of jQuery developers (and John Resig in
> particular).
Doubtful. Rather, I think the cooler heads who translated his rants
into something more useful had an impact. Discussion went on between
people who shared his technical observations but don't have his
negativity. There are other smart people in the world who know about
JS and are interested in jQuery, but aren't so vocal in public. He's
very vain to think that he was listened to so closely and that his
"contributions" actually mattered.
> It is therefore not logical of you to imply that he should better cease
> these efforts. If anything, his efforts might be instrumental in changing
> jQuery into something that can be truthfully recommended by other
> knowledgeable developers one day;
And yet he has repeatedly said that he has no interest in helping to
improve the library, or ANY library. So I would think that he would
have no interest in pointing out jQuery's flaws, in the hopes that it
would fail miserably and prove his point.
> a fact that, I imagine, would be
> appreciated by you the most.
Not at all. I currently have no problems with jQuery with what I use
it for, and if I did have problems I'm competent enough to fix them
myself. The things he rants about are not rocket science. Sometimes
I'm amazed that he pats himself on the back so much for recognizing
the obvious.
Matt Kruse
kangax
> Lasse Reichstein Nielsen wrote:
[...]
>> Anyway, I wouldn't use "arguments.length", because it makes the
>> Javascript engine need to create the arguments object.
>
> That the arguments object is not created when not used is an unfounded
> assumption, or rather wishful thinking on your part in order to support your
> argument. The ECMAScript Specification, Edition 3 Final, widely implemented
> as opposed to the ES 4+(!) dreaming, says otherwise.
I would assume that Lasse, as someone working on Chromium (afaik),
should know the intricacies of Javascript engines quite well and is
probably stating arguments rather than "wishfully thinking".
In any case, I just asked one of the WebKit reviewers - Cameron Zwarich
- whether an `arguments` object is created when an `arguments`
identifier is not present in a function body.
He said:
[10:48am] cpst:
kangax: if 'arguments' is mentioned in the body of the function, it
creates it
[10:49am] cpst:
kangax: otherwise it creates it the first time f.arguments is accessed
He pointed me to this particular optimization in a 37050 changeset -
<http://trac.webkit.org/changeset/37050>
He also mentioned that:
[10:57am] cpst:
V8 does something similar, you could find it in their source by
searching for arguments
I don't have time to search through V8, but have all the reasons to
trust him.
On a side note, hasn't somebody already demonstrate here the actual
performance tests and how functions without `arguments` (or rather those
using alternative means to access whatever would have been accessed via
`arguments`) do indeed execute faster?
--
kangax
Jorge
>
> On a side note, hasn't somebody already demonstrate here the actual
> performance tests and how functions without `arguments` (or rather those
> using alternative means to access whatever would have been accessed via
> `arguments`) do indeed execute faster?
Yes we did: in the "closure vs rewrite" thread:
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/1919a68bd6fea63e
"eval & arguments are expensive":
http://homepage.mac.com/jorgechamorro/cljs/030/
--
Jorge.
David Mark
> On Apr 1, 3:18 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > You are so colossally ignorant.
> > [snip]
> > What a cop-out.
>
> Why do you continue to invest so much time in these jQuery flame-wars?
Nothing I have posted here can be considered a flame. And I can't
stand having to correct you over and over, year after year. Will you
shut up about jQuery now?
>
> You obviously don't use jQuery, so you shouldn't care about its
> quality.
You don't use the plague. Why should you care about it's eradication.
>
> You surely don't recommend it to anyone, so you don't have to worry
> about its improvements or roadmap or bug list, etc.
My information is provided to save people a lot of time by skipping
the jQuery portion of the learning curve. Same goes for any of those
libraries (e.g. Prototype, MooTools.) I'm writing a book on the
subject as well. What business is it of yours?
>
> If you think it breaks web sites that you use, then
You can't see the forest for the trees.
> a) There are an awful lot of worse scripts out there that break sites
Worse in what way? And if you come in here recommending those, you'll
have to them too.
> and I'd think you'd complain about them
I do. Every time they are mentioned.
> b) Your approach to improving the broken web you use is quite
> ineffective
You seem alone in that assessment. If Resig and his bunch weren't so
slow to figure things out and do actual work (as opposed to putting up
rock star Websites), it would be even more effective.
>
> If it just annoys the crap out of you that code exists and is used
> that is not perfect or even logically sound, then you must be annoyed
> by a _lot_ of things you see. I'd guess that some time spent with a
> therapist would be more helpful than hours spent in jQuery
> discussions.
I do weary of these "flame wars" with you. Never you mind what annoys
me, why it might annoy me or anything else about me. You've got
plenty of other things to worry about.
>
> And if it really just bugs you to the core that a person like John
> Resig could get more attention, more popularity, more accolades, more
LOL. Resig gets a lot more negative attention, that's for sure.
Popularity? Are you in high school? Have you seen his friends?
> following, and more pats on the back than you - even though you view
> yourself as far superior and more deserving of the praise - well, get
> used to it.
The praise for what? Resig never got any praise for anything I did
and I never got blamed for any of his mistakes. What are you saying?
Everything is some sort of race with you.
>
> So... what is it? Where does all this anger and annoyance come from?
Who says I am angry? Do you even know me?
> Why do you continue this jQuery bashing repeatedly? Haven't you made
*You* asked me to review the piece of shit. Twice. Your reaction has
been similarly petulant both times. Don't bother making any further
requests for guidance.
> your point over and over and over? What do you hope to gain? You say
Again, none of your business, pal.
> you have no desire to help improve such a flawed library as jQuery,
No? Then why have I done it? I'd say I'm the only one exerting any
positive influence on it at all. Where would they be without me?
Likely listening to you swear up and down that jQuery is free of
browser sniffing (that's where they were in fall 2007, remember?)
> yet you repeatedly point out its short-comings. Why do you bother?
Again.
David Mark
> On Apr 1, 8:58 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > The most compelling reason for analyzing and criticizing a piece of software
> > would be, of course, to provide a basis for a recommendation to others as to
> > why not to use it, and maybe as to why they should use something else
> > instead
>
> I agree. But if that were truly his intention, then he is going about
> it the wrong way because it's not working.
Seems it is working spectacularly. If only you knew what "it" is.
What a babbling buffoon. You sound severely rattled.
[snip]
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> The most compelling reason for analyzing and criticizing a piece of software
>> would be, of course, to provide a basis for a recommendation to others as to
>> why not to use it, and maybe as to why they should use something else
>> instead
>
> I agree. But if that were truly his intention, then he is going about
> it the wrong way because it's not working. Insulting those you are
> trying to help will not accomplish the goal. Bashing the author of the
> "bad" code will not help the cause. Being a jerk in public only makes
> people _less_ interested in what he has to say.
It is a capital mistake to theorize before you have all the evidence.
It biases the judgment.
-- "Sherlock Holmes" in A. C. Doyle's "A Study in Scarlet"
> Also, he rarely recommends better alternatives that are really helpful
> to people.
But he does.
> He just criticizes jQuery and points out the flaws.
And that is good so. Because nobody else appears to be inclined to do it
(no wonder given that source code), and the flaws need to be pointed out.
In fact, I have marked many of his so-called rants for later reference
because they will help me to avoid the observed mistakes when updating my
libraries.
> So I don't think this "compelling reason" is what's behind his actions.
Non sequitur.
>> However, evidently Davids comments and occasional rants did have a
>> positive effect on the thinking of jQuery developers (and John Resig in
>> particular).
>
> Doubtful. Rather, I think the cooler heads who translated his rants
> into something more useful had an impact. [...]
See? Cause and effect.
>> It is therefore not logical of you to imply that he should better cease
>> these efforts. If anything, his efforts might be instrumental in changing
>> jQuery into something that can be truthfully recommended by other
>> knowledgeable developers one day;
>
> And yet he has repeatedly said that he has no interest in helping to
> improve the library,
Yet he has made a number of postings not only here but where those who are
interested in the "library" meet (virtually). That they are not listening
to what he is saying would be, evidently, as much as their fault as is his
when stepping over the line in doing that sometimes. But I can accept that
minor flaw in his argumentation as long as the arguments themselves are
sound, and I can see the outcome as overall helpful, which I do.
> or ANY library.
No, he has (and others have) repeatedly pointed out that the problem lies
with the underlying concept of a general-purpose library, and I agree. You
should take the time to read the postings here more thoroughly.
> So I would think that he would have no interest in pointing out jQuery's
> flaws, in the hopes that it would fail miserably and prove his point.
jQuery has already failed to provide the solution it advertises to be. That
much should be obvious. That there are individuals who cling to using it,
who find all kinds of excuses for using it as if that was a matter of life
and death (well, given their position in the learning curve, it certainly
must look that way) does not matter.
>> a fact that, I imagine, would be appreciated by you the most.
>
> Not at all. I currently have no problems with jQuery with what I use
> it for, and if I did have problems I'm competent enough to fix them
> myself. The things he rants about are not rocket science. Sometimes
> I'm amazed that he pats himself on the back so much for recognizing
> the obvious.
I'm afraid you miss the point here. You of all people would appreciate more
knowledgeable people recommending and using jQuery as a result of
improvement, wouldn't you? But that cannot be achieved if no improvements
are made, and it doesn't look as if those improvements would be coming from
the original author within a reasonable amount of time. Therefore, it does
not make sense if you try to block attempts at improvement right from the
start, however bad-worded, full-mouthed, misguided, or ultimately futile
because of largely ignorant readers they may seem.
PointedEars
David Mark
> I wrote a reply to this, but apparently Google Groups puked on it, so
> I'll summarize...
Dog ate your homework?
>
> On Apr 1, 2:54 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Let me make it clear to you. That method is poorly designed and
> > executed and is completely unnecessary.
>
> So?
>
So nothing. Never mind. I have no more time for you.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Lasse Reichstein Nielsen wrote:
>>> Anyway, I wouldn't use "arguments.length", because it makes the
>>> Javascript engine need to create the arguments object.
>> That the arguments object is not created when not used is an unfounded
>> assumption, or rather wishful thinking on your part in order to support your
>> argument. The ECMAScript Specification, Edition 3 Final, widely implemented
>> as opposed to the ES 4+(!) dreaming, says otherwise.
>
> I would assume that Lasse, as someone working on Chromium (afaik),
I wouldn't know.
> should know the intricacies of Javascript engines quite well and is
> probably stating arguments rather than "wishfully thinking".
Of that particular ECMAScript implementation for sure. There is no such
thing as a "Javascript engine".
> In any case, I just asked one of the WebKit reviewers - Cameron Zwarich
> - whether an `arguments` object is created when an `arguments`
> identifier is not present in a function body.
>
> He said:
>
> [10:48am] cpst:
> kangax: if 'arguments' is mentioned in the body of the function, it
> creates it
>
> [10:49am] cpst:
> kangax: otherwise it creates it the first time f.arguments is accessed
>
> He pointed me to this particular optimization in a 37050 changeset -
> <http://trac.webkit.org/changeset/37050>
>
> He also mentioned that:
>
> [10:57am] cpst:
> V8 does something similar, you could find it in their source by
> searching for arguments
>
> I don't have time to search through V8, but have all the reasons to
> trust him.
Thanks. So that would be JSCore and V8; about, say, 5% of the market? What
difference does it make for past ECMAScript implementations still in use,
and current, let alone future ones?
> On a side note, hasn't somebody already demonstrate here the actual
> performance tests and how functions without `arguments` (or rather those
> using alternative means to access whatever would have been accessed via
> `arguments`) do indeed execute faster?
If I knew, I would have replied differently. If it was Jorge, I couldn't
know, and his test cases and results would be most certainly flawed.
PointedEars
Matt Kruse
> And I can't
> stand having to correct you over and over, year after year. Will you
> shut up about jQuery now?
I'm not sure what you "correct" me about. I agree with most of your
technical critiques of the code. I agree with your conclusions about
its badly-designed API. I agree that John Resig seems like he's
learning as he goes and doesn't seem to have a solid fundamental
understanding of js or many years of js development experience. I
agree that jQuery could be greatly improved. I agree that it's hack-
ish.
We just seem to disagree on how to say it and what to do about it.
> My information is provided to save people a lot of time by skipping
> the jQuery portion of the learning curve. Same goes for any of those
> libraries (e.g. Prototype, MooTools.)
Yet you seem to ignore the reality that the majority of the web
development world seems to disagree with you. Do you think you and the
minority are "right" and everyone else is just stupid? Or do you think
perhaps that you can't see the forest through the trees? If all this
were just an exercise in logic and robust coding, you'd be writing the
Bible for it. But there's so much more to it than that.
> I'm writing a book on the
> subject as well. What business is it of yours?
I'm curious. Will it have ninjas?
> If Resig and his bunch weren't so
> slow to figure things out and do actual work (as opposed to putting up
> rock star Websites), it would be even more effective.
He is clearly more interested in marketing and the jQuery brand than
he is about pure technical quality, and using that popularity to
support his travels, talks, books, etc. That's been obvious for a long
time. I don't blame him. Sounds fun.
> I do weary of these "flame wars" with you.
Me too, it quickly becomes boring. I wish we could direct this energy
into a more beneficial direction. For example, I understand your
points about attributes vs. properties and how the attr() function is
a mangled mess of the two. I'd like to learn more about some of the
specific problems that I may not have experience with, but that's
buried under pages of sarcastic comments and negative tone. Doesn't
seem helpful.
What I really wish is that we could branch jQuery, simplify the API,
re-state some goals, throw out the shit, and fix the things that are
broken. But in the end be left with something that would be
recognizable as a "re-invented" jQuery that competent developers
wouldn't be afraid of adopting, and novice js developers could adopt
without spending months or years learning everything they would need
to in order to produce something similar. Unfortunately, that will
never happen. So jQuery is still left is the next-best option for me
and many others.
> > following, and more pats on the back than you - even though you view
> > yourself as far superior and more deserving of the praise - well, get
> > used to it.
> The praise for what? Resig never got any praise for anything I did
> and I never got blamed for any of his mistakes. What are you saying?
It seems to me that you're annoyed at the praise and attention that
John Resig seems to get (whether you like it or not, jQuery is
enormously succesfull), and you wish the world would just understand
that you have the better way. But people won't listen. *shrug* My
characterization may be way off. It doesn't much matter.
> > you have no desire to help improve such a flawed library as jQuery,
> No? Then why have I done it?
I don't believe you have.
> I'd say I'm the only one exerting any
> positive influence on it at all.
> Where would they be without me?
Delusions of grandeur. But that's okay, I guess.
Matt Kruse
Matt Kruse
It was an honest question.
You have identified flaws in jQuery. But what does that mean to you?
Because it seems to mean different things to different people.
To me, it means:
a) The quality of the underlying code is suspect
b) I need to be careful if I choose to use this method
c) I may be able to help improve it for future versions
Finding flaws in a product (even severe ones) is not necessarily a
reason not to use it. I've used Windows for a decade, despite its huge
flaws. I've spent countless hours just trying to get the damn thing to
work right and not crash. But I still use it. Linux is technically
superior in so many ways. But I choose not to use it. Weird, isn't it?
My point is - you have identified problems in the jQuery code. And yet
it does seem to work for most cases, for most people. So what is your
point? That the whole library should be thrown out? If so, then what
do you suggest to replace it with? You don't seem to offer any
alternatives to the countless people currently using it, other than
"go do your homework and write your own reusable code from scratch,
it's the only correct way to do it!" Great! But completely
unrealistic, and that's why people continue to flock to libraries like
jQuery despite its technical problems.
Matt Kruse
Jorge
wrote:
>
> (...) If it was Jorge, I couldn't
> know, and his test cases and results would be most certainly flawed.
>
Yes yes thanks, that's wisdom enough for today from Pointedears the
Enlightened One.
But now go back to studying and see if you are able to (finally) grasp
what's the deal with closures... jejeje
--
Jorge.
Garrett Smith
> Lasse Reichstein Nielsen wrote:
>> David Mark writes:
>>> On Mar 30, 3:12 pm, Thomas Allen <thomasmal...@gmail.com> wrote:
>>>> I'd go with checking Arguments.length.
>>> And all known agents will dutifully throw an exception.
>> .... because "arguments" shouldn't be capitalized.
>> Oh, do try to be a little helpful, instead of wasting time on typos.
>
> However, that guy is notorious for not understanding what he's doing and
> thinking otherwise.
>
>> Anyway, I wouldn't use "arguments.length", because it makes the
>> Javascript engine need to create the arguments object.
>
I would avoid that, too, for the same reason. Using |arguments| prevents
an implementation from making an optimization.
> That the arguments object is not created when not used is an unfounded
> assumption, or rather wishful thinking on your part in order to support your
> argument. The ECMAScript Specification, Edition 3 Final, widely implemented
> as opposed to the ES 4+(!) dreaming, says otherwise.
An ECMAScript implementation guarantees behavior. (So much for debunking
an "unfounded assuption"). If a function body does not make a reference
to |arguments| or |eval|, an implementation could create an optimized
call for that function.
Implementations may make a static analysis of the function to determine
if an optimized call can be performed and perform such optimized call,
if the side effects of such call would not be observable (excluding the
improved performance time).
It has been demonstrated that implementations actually seem to do this.
However, it the question is to determine if a function foo:-
function foo(x){
alert(x === undefined);
}
- has been passed an argument, as in:-
foo(undefined)
- as opposed to -
foo()
- would be to check the arguments object.
10.1.3 guarantees that missing parameters get value |undefined|.
| If the caller supplies fewer parameter values than there are formal
| parameters, the extra formal parameters have value undefined.
>
> So much for being helpful.
>
This has been discussed on here in detail before.
Garrett
David Mark
> On Apr 1, 12:23 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > And I can't
> > stand having to correct you over and over, year after year. Will you
> > shut up about jQuery now?
>
> I'm not sure what you "correct" me about. I agree with most of your
> technical critiques of the code. I agree with your conclusions about
Evidently, you don't understand the critiques at all, other than the
most obvious (e.g. browser sniffing.)
> its badly-designed API. I agree that John Resig seems like he's
> learning as he goes and doesn't seem to have a solid fundamental
> understanding of js or many years of js development experience. I
> agree that jQuery could be greatly improved. I agree that it's hack-
> ish.
Yet you disagree that it should be avoided. (!)
>
> We just seem to disagree on how to say it and what to do about it.
How to say what?
>
> > My information is provided to save people a lot of time by skipping
> > the jQuery portion of the learning curve. Same goes for any of those
> > libraries (e.g. Prototype, MooTools.)
>
> Yet you seem to ignore the reality that the majority of the web
> development world seems to disagree with you.
Of course not. The majority of Web developers have no idea about
Javascript or browser scripting in general. This is news?
> Do you think you and the
> minority are "right" and everyone else is just stupid?
Ignorant would be more kind, but doesn't always apply.
> Or do you think
> perhaps that you can't see the forest through the trees? If all this
Have you noticed that every time I say something it pops up later in
one of your posts? A similar situation exists with the jQuery code,
but it takes years, rather than hours to reflect.
> were just an exercise in logic and robust coding, you'd be writing the
> Bible for it. But there's so much more to it than that.
Much more to what than what?
>
> > I'm writing a book on the
> > subject as well. What business is it of yours?
>
> I'm curious. Will it have ninjas?
How many Ninjas does it take to create an XHR object or set opacity?
>
> > If Resig and his bunch weren't so
> > slow to figure things out and do actual work (as opposed to putting up
> > rock star Websites), it would be even more effective.
>
> He is clearly more interested in marketing and the jQuery brand than
> he is about pure technical quality, and using that popularity to
> support his travels, talks, books, etc. That's been obvious for a long
> time. I don't blame him. Sounds fun.
So he sells worthless books, perpetuating his fanciful ideas about
browser scripting, lots of neophytes buy in to them, spreading junk
code from one corner of the Web to the next and you don't blame him a
bit. Who do you blame?
>
> > I do weary of these "flame wars" with you.
>
> Me too, it quickly becomes boring. I wish we could direct this energy
> into a more beneficial direction. For example, I understand your
> points about attributes vs. properties and how the attr() function is
> a mangled mess of the two.
So?
> I'd like to learn more about some of the
> specific problems that I may not have experience with, but that's
> buried under pages of sarcastic comments and negative tone.
You are so easily distracted? What are you, a baby?
> Doesn't
> seem helpful.
There's an overused sentiment.
>
> What I really wish is that we could branch jQuery, simplify the API,
Branch jQuery? Why fix something that is "not broken?"
> re-state some goals, throw out the shit, and fix the things that are
> broken.
So you admit it is broken?
> But in the end be left with something that would be
> recognizable as a "re-invented" jQuery that competent developers
> wouldn't be afraid of adopting, and novice js developers could adopt
> without spending months or years learning everything they would need
> to in order to produce something similar.
And therein lies the flaw in your thinking.
> Unfortunately, that will
> never happen. So jQuery is still left is the next-best option for me
> and many others.
Next-best option for what and for whom? After all of this, you are
still going to use jQuery?
>
> > > following, and more pats on the back than you - even though you view
> > > yourself as far superior and more deserving of the praise - well, get
> > > used to it.
> > The praise for what? Resig never got any praise for anything I did
> > and I never got blamed for any of his mistakes. What are you saying?
>
> It seems to me that you're annoyed at the praise and attention that
> John Resig seems to get (whether you like it or not, jQuery is
> enormously succesfull), and you wish the world would just understand
No, it is a colossal failure. It would be less of a colossal failure
if less people had rushed to adopt it.
> that you have the better way. But people won't listen. *shrug*
LOL. The people that matter are listening. You just aren't a member
of that club.
> My
> characterization may be way off. It doesn't much matter.
Nothing matters does it?
>
> > > you have no desire to help improve such a flawed library as jQuery,
> > No? Then why have I done it?
>
> I don't believe you have.
And I don't much care what you believe.
>
> > I'd say I'm the only one exerting any
> > positive influence on it at all.
> > Where would they be without me?
>
> Delusions of grandeur. But that's okay, I guess.
You are the last guy who should crack about delusions. :)
David Mark
> On Apr 1, 12:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Apr 1, 9:58 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> > > On Apr 1, 2:54 am, David Mark <dmark.cins...@gmail.com> wrote:
> > > > Let me make it clear to you. That method is poorly designed and
> > > > executed and is completely unnecessary.
> > > So?
> > So nothing. Never mind. I have no more time for you.
>
> It was an honest question.
>
> You have identified flaws in jQuery. But what does that mean to you?
It means:
1. It is broken.
2. The people charged with fixing it are incapable.
3. It complicates, rather than simplifies
> Because it seems to mean different things to different people.
To quote John Resig: "broke is broke."
>
> To me, it means:
> a) The quality of the underlying code is suspect
LOL. It's been booked, printed and sentenced to life (three strikes
and all.)
> b) I need to be careful if I choose to use this method
You are just inconceivably thick. Do you normally need to "be
careful" when setting DOM properties?
http://jquery.open2space.com/node/13
http://mindforks.blogspot.com/2008/11/using-attr-for-aria-in-jquery-ui.html
http://www.ibm.com/developerworks/web/library/wa-jquery2/
It's too late. Those jackasses should have taken care when they
*wrote* the code. Would have prevented others from writing about
their nonsense as if it were the greatest thing since sliced bread.
> c) I may be able to help improve it for future versions
What does that mean to a developer who needs to deploy a site
*today*? That they might be able to upgrade the whole interdependent
mess at some point in the future? Considering the lag with the plug-
ins and widgets (which you yourself have compared to the plague), that
sounds like a very hard way to go.
>
> Finding flaws in a product (even severe ones) is not necessarily a
> reason not to use it. I've used Windows for a decade, despite its huge
I don't care how long you have been using Windows. Windows vs. Mac
bears no resemblance to jQuery vs. common sense.
> flaws. I've spent countless hours just trying to get the damn thing to
> work right and not crash. But I still use it.
What's the definition of insanity?
> Linux is technically
> superior in so many ways. But I choose not to use it. Weird, isn't it?
Not really. But then I know you.
>
> My point is - you have identified problems in the jQuery code. And yet
> it does seem to work for most cases, for most people.
Software that does seem to work for most cases, for most people is not
to be recommended. Especially if you don't know *which* people or
cases. Certainly the Web would be last place for such code.
> So what is your
> point? That the whole library should be thrown out?
For the love of God, yes.
> If so, then what
> do you suggest to replace it with? You don't seem to offer any
> alternatives to the countless people currently using it, other than
There was a time in history when countless people had the plague.
What should they have replaced that with?
> "go do your homework and write your own reusable code from scratch,
Not the "write everything from scratch" argument again. Are you
kidding?
> it's the only correct way to do it!" Great! But completely
> unrealistic, and that's why people continue to flock to libraries like
> jQuery despite its technical problems.
Flock is definitely the right word. You better watch out, there may
be dogs about.
Matt Kruse
> > its badly-designed API. I agree that John Resig seems like he's
> > learning as he goes and doesn't seem to have a solid fundamental
> > understanding of js or many years of js development experience. I
> > agree that jQuery could be greatly improved. I agree that it's hack-
> > ish.
> Yet you disagree that it should be avoided. (!)
Yes. I've tried to explain why, but you refuse to open your mind.
That's okay, I understand.
> > Do you think you and the
> > minority are "right" and everyone else is just stupid?
> Ignorant would be more kind, but doesn't always apply.
Well, I guess being a genius is a lonely job.
> > Or do you think
> > perhaps that you can't see the forest through the trees? If all this
> Have you noticed that every time I say something it pops up later in
> one of your posts?
I know, I do it intentionally. I find it amusing.
> > I'm curious. Will it have ninjas?
> How many Ninjas does it take to create an XHR object or set opacity?
a) 42
b) 420
c) Over 9,000!!!
Ninja Parade Slips By Town Unnoticed Once Again
http://www.youtube.com/watch?v=WtR2m20C2YM
> So he sells worthless books, perpetuating his fanciful ideas about
> browser scripting, lots of neophytes buy in to them, spreading junk
> code from one corner of the Web to the next and you don't blame him a
> bit. Who do you blame?
Why must blame be placed? He's making the best of his situation, like
a Rock Star enjoying a #1 hit. Party on, John.
> And therein lies the flaw in your thinking.
Ah, finally. I've been looking for it.
> Next-best option for what and for whom? After all of this, you are
> still going to use jQuery?
Yes. Someday you'll be wise enough to understand.
> > My
> > characterization may be way off. It doesn't much matter.
> Nothing matters does it?
Certainly not to me. But I do find it interesting.
Matt Kruse
David Mark
> On Apr 1, 4:00 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > its badly-designed API. I agree that John Resig seems like he's
> > > learning as he goes and doesn't seem to have a solid fundamental
> > > understanding of js or many years of js development experience. I
> > > agree that jQuery could be greatly improved. I agree that it's hack-
> > > ish.
> > Yet you disagree that it should be avoided. (!)
>
> Yes. I've tried to explain why, but you refuse to open your mind.
> That's okay, I understand.
>
> > > Do you think you and the
> > > minority are "right" and everyone else is just stupid?
> > Ignorant would be more kind, but doesn't always apply.
>
> Well, I guess being a genius is a lonely job.
>
> > > Or do you think
> > > perhaps that you can't see the forest through the trees? If all this
> > Have you noticed that every time I say something it pops up later in
> > one of your posts?
>
> I know, I do it intentionally. I find it amusing.
I find it annoying.
>
> > > I'm curious. Will it have ninjas?
> > How many Ninjas does it take to create an XHR object or set opacity?
>
> a) 42
> b) 420
> c) Over 9,000!!!
>
> Ninja Parade Slips By Town Unnoticed Once Againhttp://www.youtube.com/watch?v=WtR2m20C2YM
One of Resig's stupid Javascript tricks videos would have been more
appropriate.
>
> > So he sells worthless books, perpetuating his fanciful ideas about
> > browser scripting, lots of neophytes buy in to them, spreading junk
> > code from one corner of the Web to the next and you don't blame him a
> > bit. Who do you blame?
>
> Why must blame be placed? He's making the best of his situation, like
> a Rock Star enjoying a #1 hit.
This is software. It's not a matter of taste.
> Party on, John.
Fat, drunk and stupid is no way to go through life, boy.
>
> > And therein lies the flaw in your thinking.
>
> Ah, finally. I've been looking for it.
>
> > Next-best option for what and for whom? After all of this, you are
> > still going to use jQuery?
>
> Yes. Someday you'll be wise enough to understand.
Some day you will admit your mistake and change. Or you will remain a
buffoon. There's really no middle ground.
[snip]
David Mark
>
> http://www.nabble.com/attr(%22href%22)-giving-full-path-instead-of-re...
Oops, didn't realize that was actually a GG.
http://groups.google.com/group/jquery-en/browse_thread/thread/ea68e18af9f66296#
This post is from a week ago, so it overlaps our recent discussion
about this issue, which is basically a re-hash of an argument from the
fall of 2007.
It starts out:
"I'm wanting to read in the exact string that's contained in an
anchor's href attribute in order to use it as the POST variable list
for an Ajax call to a PHP script, however in IE6 and 7 the string read
from the href attribute ends up being the absolute path, not just the
href attribute. Here's exactly what's happening:
vars = $("a").attr("href");
alert(vars);
<a href="page=2">This should return "page=2"</a>
What I get when running locally in all browsers but IE is what is
expected, an alert box with page=2 in it. In IE, I get "http://
localhost/page=2". Is there some way to get it to behave either one
way or the other in all browser instances? I really don't want to have
to detect for IE, then extract what I want from the string if it is."
Sure, in this example:
vars = document.getElementsByTagName('a')[0].href
But this wasn't posted here. Instead he got this:
"http://www.glennjones.net/Post/809/getAttributehrefbug.htm describes
the issue and gives a solution."
Not exactly, but the solution proposed was better than this:
"$("a")[0].href will probably work consistently."
How elegant, we are to bypass the jQuery "convenience" method as it
doesn't do anything predictable (at least to the uninitiated.) The
docs didn't say anything about that.
After a bit of confusion, the OP added:
"The way I currently have it will not work with javascript turned off
either. I'm doing it this way only because the client is requiring the
user to have Javascript enabled to use the site (it's a backend system
for very specific clients). They want to add all sorts of animations
and effects like everyone wants to do once they see JQuery animations
in action."
jQuery expert @2 replied:
"IE has a second "flag" argument for getAttribute that, when set to 2,
is supposed to get the literal value of the attribute rather than
their special-sauce value.
So, this.getAttribute('href', 2) *should* get the relative href.
(note: no need to do $(this)[0] ; this works just fine)
jQuery uses that flag internally, so .attr('href') should do the same
thing:
var attr = !jQuery.support.hrefNormalized && notxml && special
// Some attributes require a special call on IE
? elem.getAttribute( name, 2 )
: elem.getAttribute( name );
I believe that this works in every case except when the href is set
via JavaScript. In that case, I'm not sure anything can be done."
Except when it doesn't work. Certainly he meant in every case that he
knows about, except when jQuery is used to set the attribute as it
uses the attr method, so there is no telling what to expect from the
DOM after that. GIGO.
And why is a code dissection needed here anyway? Couldn't they have
pointed the OP to the documentation? Perhaps they knew it was as
confused as they are.
OP:
"... I'm pretty sure I'm reading you right, but are you saying that by
all accounts JQuery should account for this and return the string-
literal value of href and not IE's absolute path? If so, it's not
working properly ... That means that if JQuery is supposed to sort
this out for me, it's not. If you meant that I'd absolutely have to
use Javascript's getAttribute(), then I'll try that and see if it
works."
Sure, try "Javascript's getAttribute" that and see if it works. This
is programming by collaborative misunderstanding.
OP:
"After replacing $(this).attr("href") with this.getAttribute("href",
2) I get the same result. If I output the attribute, IE still shows
the absolute path."
All of this flailing to get a consistent result with:
this.href;
Not there yet, but it does have a (more or less) happy ending.
jQuery support:
"Yes, I believe you're reading me right. Strange, though. I'm not able
to reproduce the problem you're having. Take a look here:"
Not strange at all. Neither has mentioned which version of jQuery
they are using and only one has indicated an IE version.
After some more suggestions about parsing URI's (!), the OP finally
figures it out for himself:
"Right, it's not hard, it was just unexpected is all. I guess I've
gotten used to JQuery working the same in "all browsers."
I've got it working now with some old-fashioned Javascript."
Get used to jQuery not working the same in all browsers.
So he has noted a landmine on *his* map. The others seem oblivious
and completely ignorant of the fact that the attr method makes getting
and setting properties *much* more complicated than it needs to be and
leads to code that changes behavior from one version to the next and
is virtually impossible to debug. Wasn't jQuery supposed to save you
from "good old-fashioned Javascript?"
Then this is this ominous coda:
"I experienced the same problem while developing a plugin that does
some tricks with the page content during the ready event. I noticed
that attr('href') works fine if I don't manipulate the body tag
content. IE won't return the correct href attribute if I do so.
The code I used to workaround the problem looks like this:
$('a').attr('xref', function() {
return $(this).attr('href');
});
...
document.body.innerHTML = someContent + document.body.innerHTML;
...
$('a').attr('href', function() {
return $(this).attr('xref');
}).removeAttr('xref');
Hope this helps."
Not by a long shot. Notice the "if I manipulate" (with jQuery)
comment. Again, GIGO. And advising people to add expandos to bridge
the gap in jQuery's attribute logic is obviously ludicrous. Now how
many people will run out and do just that?
Nobody has posted to the thread since, so I assume the issue is
considered closed. Doesn't really matter as they obviously can't
rewrite the attr method (for fear of breaking workarounds based on bad
assumptions.)
So is this really the "next best thing" to DOM properties? And is
this really a viable support group?
Lasse Reichstein Nielsen
> That the arguments object is not created when not used is an unfounded
> assumption, or rather wishful thinking on your part in order to support your
> argument.
Mmm, no.
I know for certain that at least one ES3 implementation optimizes away
the arguments object creation, and simple tests suggests that others
do the same (speed of calling a function decreases if it contains an
identifier named "arguments", even if it isn't used).
> The ECMAScript Specification, Edition 3 Final, widely implemented
> as opposed to the ES 4+(!) dreaming, says otherwise.
The specification is not an implementation specification, but a
behavioral specification. If the arguments object isn't referenced,
then the behavior doesn't change if it's not created.
> So much for being helpful.
Try it! Add the following to a page and try it in different browsers:
<script type="text/javascript">
function testArgs() {
function f1(a) {
if (true) { return; } else { return arguments.a; }
}
function f2(a) {
if (true) { return; } else { return a.a; }
}
var t0 = new Date();
for (var i = 0; i < 100000; i++) {
f1();
}
var t1 = new Date();
for (var i = 0; i < 100000; i++) {
f2();
}
var t2 = new Date();
return (t1 - t0) / (t2 - t1);
}
window.onload = function(){ alert(testArgs()); };
</script>
My results (approx):
Opera 9.6 : 8
Firefox 3.0.8 : 1
Chrome 2.0.171.0 : 5.5
Safari 4 beta : 8
IE 7 : 1
So three out of five browsers do indeed get slower calling a function that
mentions the arguments object, even if it isn't accessed at all.
So much for being right :)
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'
kangax
> kangax wrote:
[...]
>> should know the intricacies of Javascript engines quite well and is
>> probably stating arguments rather than "wishfully thinking".
>
> Of that particular ECMAScript implementation for sure. There is no such
> thing as a "Javascript engine".
Aren't those interchangeable? I see both WebKit [1] and Mozilla [2]
calling their "ECMAScript implementations" exactly that - "Javascript
engines".
[...]
>> I don't have time to search through V8, but have all the reasons to
>> trust him.
>
> Thanks. So that would be JSCore and V8; about, say, 5% of the market? What
> difference does it make for past ECMAScript implementations still in use,
> and current, let alone future ones?
No difference of course. The point was to merely find out whether *any*
of the currently existing implementations perform the optimization, and
to see whether this is a "wishful thinking" on our part or is an actual
fact.
Now we know they do.
Just to speculate:
I see that the change in WebKit was committed ~6 months ago. That means
that newly released Safari 4 beta probably already includes it. Upcoming
(free) iPhone update (3.0?) will most likely include it as well;
that's 30 million (only mobile) browsers. I suspect Mozilla to follow
the lead with similar optimizations (if they haven't already done so) in
TraceMonkey, which is part of upcoming Firefox 3.1 (IIRC); new versions
of Firefox are known to be replacing older ones with great speed.
I think such optimizations will matter more in the near future, although
given the tremendous rise in execution speed of current "ECMAScript
implementations", the difference might not be worth attention.
>
>> On a side note, hasn't somebody already demonstrate here the actual
>> performance tests and how functions without `arguments` (or rather those
>> using alternative means to access whatever would have been accessed via
>> `arguments`) do indeed execute faster?
>
> If I knew, I would have replied differently. If it was Jorge, I couldn't
> know, and his test cases and results would be most certainly flawed.
I think his tests were fine. Take a look at his reply to my message in
this thread, which includes a link to the tests.
[...]
[1] http://webkit.org/blog/189/announcing-squirrelfish/
[2] https://wiki.mozilla.org/JavaScript:TraceMonkey
--
kangax
Thomas 'PointedEars' Lahn
> On Apr 1, 4:00 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>> its badly-designed API. I agree that John Resig seems like he's
>>> learning as he goes and doesn't seem to have a solid fundamental
>>> understanding of js or many years of js development experience. I
>>> agree that jQuery could be greatly improved. I agree that it's hack-
>>> ish.
>> Yet you disagree that it should be avoided. (!)
>
> Yes. I've tried to explain why, but you refuse to open your mind.
> That's okay, I understand.
Maybe it is not so much a matter of his mind closed but of the
all-to-obvious contradiction in your argumentation that I for one don't buy
either.
Why do you insist on using something that you *know* is borken? Why do you
not use (and recommend) something else that you *know* (or should know) to
be working instead? Should such ignorant behavior not carry the mark of
utter incompetence?
PointedEars
Matt Kruse
wrote:
> Why do you insist on using something that you *know* is borken?
I use Windows, which is extremely broken. I use IE6 in some cases even
though it's as broken as it gets. I use countless web sites that have
major flaws. I've often relied on batch files and hacked scripts that
got jobs done in a very ugly way and were very fragile (even broken at
times) but it was still better than NOT using them. I use lots of
things that I know are broken, because very few things are perfect.
The question isn't just "is it broken?" but rather "do the benefits
outweigh the potential risks?" And in the case of situations where I
use jQuery, they do. Some people who are crippled by analysis and
strict logic can't quite wrap their heads around that, because their
brains require everything to be perfectly logical and optimized in
order to go forward.
> Why do you
> not use (and recommend) something else that you *know* (or should know) to
> be working instead?
I do not know of a better alternative. If one were available, I would
probably use and recommend it and drop jQuery. I have no particular
attachment to jQuery, personally.
> Should such ignorant behavior not carry the mark of
> utter incompetence?
Not at all. It's being realistic. If everyone waited around for
perfectly robust and analytically correct solutions before moving
forward, people wouldn't get anywhere. Just think of how many people
have _died_ while using experimental, imperfect, flawed machines in
the name of science and progress. People know things are broken, but
they use them anyway because it's a way to take a step forward.
Luckily, using broken code won't result in death.
Hell, every time I fly I think of all the things that are potentially
broken. Wires could be bad, maybe there's more ice on the wing than
they realize, maybe a bird will hit the engine, may a cross-wind will
blow the plane off the runway. Who knows? I know the risks, and I know
that driving may actually be "safer". But the benefits outweigh the
risks, so I get on the plane.
It's perfectly reasonable to use a tool because it offers many
benefits, and trust that its flaws will be fixed as you go along and
you'll be better off in the long run. We all do it. You just may
disagree on the benefits vs. risks, and in fact it may NOT be the
right choice for you. But that's not necessarily true for everyone,
because you can't possibly know the situation that everyone finds
themselves in.
Matt Kruse
Matt Kruse
> http://groups.google.com/group/jquery-en/browse_thread/thread/ea68e18...
I just got a chance read this post and the above thread, and it looks
like the OP was confused, but the general issue is relevant.
> All of this flailing to get a consistent result with:
> this.href;
I'm kind of confused about what you mean, because simply accessing
".href" doesn't return the desired value. That's what the code in attr
() tries to fix.
I'm sure this is obvious to you, but in my version of IE6 with jQuery
1.3.2:
<a href="test.html" id="x">test</a>
document.getElementById('x').href == file:///C:/attr.html
document.getElementById('x').getAttribute('href') == file:///C:/attr.html
document.getElementById('x').getAttribute('href',2) == attr.html
$('#x').attr('href') == attr.html
So, using a simple property getter like this.href is insufficient if
you want to retrieve the actual attribute value of "test.html". The
jQuery attr() method does in fact normalize this so .attr('href')
returns what is expected. Is this not what you would expect?
> So is this really the "next best thing" to DOM properties?
Seems like an improvement over simply accessing the property, even if
implemented poorly.
Matt Kruse
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Why do you insist on using something that you *know* is borken?
>
> I use Windows, which is extremely broken.
That doesn't answer my question at all. For it is not that there are no
qualitatively better, cheaper, freer alternatives.
> I use IE6 in some cases even though it's as broken as it gets.
There are alternatives to that, too. FYI, I use IE 6 only for testing, in a
Windows emulation on GNU/Linux at home (on my notebook), and in Standalone
IE, IETester, and Virtual PC at work.
> I use countless web sites that have major flaws.
Again, why?
> I've often relied on batch files and hacked scripts that got jobs done in
> a very ugly way and were very fragile (even broken at times) but it was
> still better than NOT using them.
Because it was for a single user (you) or a limited group of users. I can
accept that; I do the same, although at least I do *strive* for perfection
there.
> I use lots of things that I know are broken, because very few things are
> perfect.
Nobody's perfect. That's no reason or excuse at all to use borken things
*knowingly* and *in spite* of the better alternatives. Especially not if
you are in a position to build better things; however, if you don't think
you are in that position, you are also in no position to make
recommendations in favor of the broken things.
> The question isn't just "is it broken?" but rather "do the benefits
> outweigh the potential risks?"
I'm afraid you are in no position to assess the potential problems, let
alone the risks, when it comes to jQuery. Your reasoning is much too biased
for that.
>> Why do you not use (and recommend) something else that you *know* (or
>> should know) to be working instead?
>
> I do not know of a better alternative. If one were available, I would
> probably use and recommend it and drop jQuery.
But the alternatives have been named here and elsewhere a hundred times or
more, and you have refused to consider them to date.
> I have no particular attachment to jQuery, personally.
I wouldn't be so sure about that. The way you unwaveringly *defend* this
junk, which maybe beautifully-looking junk (to me it reads outside as the
junk that it is inside, but there's no accounting for taste), but *junk*
nonetheless, speaks of a very deep personal attachment to it.
>> Should such ignorant behavior not carry the mark of utter incompetence?
>
> Not at all. It's being realistic. If everyone waited around for perfectly
> robust and analytically correct solutions before moving forward, people
> wouldn't get anywhere.
That argument would be sound if there was no alternative to using jQuery.
But there is.
> It's perfectly reasonable to use a tool because it offers many benefits,
> and trust that its flaws will be fixed as you go along and you'll be
> better off in the long run. We all do it.
I don't do it in spite of knowing about and having a better tool.
Definitely not.
PointedEars
Matt Kruse
wrote:
> > I do not know of a better alternative. If one were available, I would
> > probably use and recommend it and drop jQuery.
> But the alternatives have been named here and elsewhere a hundred times or
> more, and you have refused to consider them to date.
I know there are alternatives. But so far none of them have been
"better".
If you're judging purely by code quality or robustness, then sure.
There are better alternatives. But that is ignoring other factors such
as:
a) Documentation
b) Support
c) Examples
d) Simplicity of bringing new developers into the code without
learning a new API
e) Testing
f) Continuous improvement
g) Development time/speed
h) Cost
i) "Approved For Use" by IT/Mgmt
When I factor in all those things, other alternatives become less
appealing. You can argue all you want that it shouldn't be this way,
but it IS, and currently using jQuery is the best decision in some
situations. In other situations, when I consider all the factors, it
is not the best decision. It depends.
> > I have no particular attachment to jQuery, personally.
> I wouldn't be so sure about that.
Oh, I'm sure. I've been very critical of it, even in personal email
conversations with Mr. Resig. I'm pretty sure he doesn't much care for
me, but that's okay. ;)
> The way you unwaveringly *defend* this
> junk, which maybe beautifully-looking junk (to me it reads outside as the
> junk that it is inside, but there's no accounting for taste), but *junk*
> nonetheless, speaks of a very deep personal attachment to it.
If you cannot look beyond the "junkiness" of the code to see the other
possible benefits it might provide, then that's where we differ.
> That argument would be sound if there was no alternative to using jQuery.
> But there is.
I would genuinely be interested in hearing what you feel the
alternatives are and why they are the "better" choice in different
situations.
Matt Kruse
kangax
[...]
> So, using a simple property getter like this.href is insufficient if
> you want to retrieve the actual attribute value of "test.html". The
> jQuery attr() method does in fact normalize this so .attr('href')
> returns what is expected. Is this not what you would expect?
Don't forget that there are cases when IE still returns absolute path
even when given "2" flag to `getAttribute` - notably, when an anchor
element is inserted into a document via `innerHTML`:
document.body.innerHTML = '<a href="http://example.com/example">x</a>';
document.getElementsByTagName('a')[0].getAttribute('href', 2);
Yet another IE's `innerHTML` idiocy.
[...]
--
kangax
David Mark
> On Apr 1, 6:46 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> >http://groups.google.com/group/jquery-en/browse_thread/thread/ea68e18...
>
> I just got a chance read this post and the above thread, and it looks
> like the OP was confused, but the general issue is relevant.
The OP was (and likely still is confused.) The people who attempted
to help were (and certainly still are) confused. Of course the issue
is relevant (that's why I pointed it out!)
>
> > All of this flailing to get a consistent result with:
> > this.href;
>
> I'm kind of confused about what you mean, because simply accessing
> ".href" doesn't return the desired value. That's what the code in attr
> () tries to fix.
And what is the desired value? From the OP's first post:
"Is there some way to get it to behave either one
way or the other in all browser instances?"
>
> I'm sure this is obvious to you, but in my version of IE6 with jQuery
> 1.3.2:
>
> <a href="test.html" id="x">test</a>
>
> document.getElementById('x').href == file:///C:/attr.html
> document.getElementById('x').getAttribute('href') == file:///C:/attr.html
> document.getElementById('x').getAttribute('href',2) == attr.html
> $('#x').attr('href') == attr.html
>
> So, using a simple property getter like this.href is insufficient if
> you want to retrieve the actual attribute value of "test.html".
Not insufficient. That obviously won't work at all.
> The
> jQuery attr() method does in fact normalize this so .attr('href')
> returns what is expected. Is this not what you would expect?
>
> > So is this really the "next best thing" to DOM properties?
>
> Seems like an improvement over simply accessing the property, even if
> implemented poorly.
LOL. I suggest you re-read it (the thread and the code.) I'm saving
this one in case you ever open your mouth in here about jQuery
again. :)
David Mark
> Matt Kruse wrote:
>
> [...]
>
> > So, using a simple property getter like this.href is insufficient if
> > you want to retrieve the actual attribute value of "test.html". The
> > jQuery attr() method does in fact normalize this so .attr('href')
> > returns what is expected. Is this not what you would expect?
It's all nonsense. It doesn't "normalize" anything. You'd need a
four-dimensional chart to plot the results across browsers, jQuery
versions, element types, etc. Misconceptions like this are why Resig
wants SETI-like unit testing. But it is hard to test something when
you don't understand what it is supposed to do.
>
> Don't forget that there are cases when IE still returns absolute path
> even when given "2" flag to `getAttribute` - notably, when an anchor
> element is inserted into a document via `innerHTML`:
Of course. That "2" flag is the last thing anyone should count on.
Not a shock that jQuery counts on it for everything.
BTW, the jQuery "rules" regarding href|src do not apply to data or
longdesc (longDesc?) (!)
>
> document.body.innerHTML = '<a href="http://example.com/example">x</a>';
> document.getElementsByTagName('a')[0].getAttribute('href', 2);
>
> Yet another IE's `innerHTML` idiocy.
Compounded by yet another jQuery idiocy. It's like they seek out the
mines and purposely jump on them.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>>> I do not know of a better alternative. If one were available, I would
>>> probably use and recommend it and drop jQuery.
>> But the alternatives have been named here and elsewhere a hundred times or
>> more, and you have refused to consider them to date.
>
> I know there are alternatives. But so far none of them have been
> "better".
>
> If you're judging purely by code quality or robustness, then sure.
> There are better alternatives. But that is ignoring other factors such
> as:
> a) Documentation
> b) Support
> c) Examples
> d) Simplicity of bringing new developers into the code without
> learning a new API
> e) Testing
> f) Continuous improvement
> g) Development time/speed
> h) Cost
> i) "Approved For Use" by IT/Mgmt
OMG, are you living in luserland after all? *You* are the developer, the
expert (in your team, I hope), who apparently needs all that stuff jQuery
offers; are you not capable of providing something better than jQuery that
does the same, after all this time and all these discussions?
> When I factor in all those things, other alternatives become less
> appealing. You can argue all you want that it shouldn't be this way,
> but it IS,
Only because *you* make it so. If you state your case and tell the suits
that what they want is an incredibly bad idea, if you explain why, and if
you offer alternatives to them, maybe some more expensive now but also more
profitable in the mid-term or long-term, they will listen. BTDT.
> and currently using jQuery is the best decision in some situations.
Shortsightedness leaving you with the one option of shooting yourself in
the foot, that must be considered the best (and only) option that remains.
Cause and effect. Eliminate the cause, and you will be left with more, and
better options.
> In other situations, when I consider all the factors, it
> is not the best decision. It depends.
Hmmm.
>> The way you unwaveringly *defend* this
>> junk, which maybe beautifully-looking junk (to me it reads outside as the
>> junk that it is inside, but there's no accounting for taste), but *junk*
>> nonetheless, speaks of a very deep personal attachment to it.
>
> If you cannot look beyond the "junkiness" of the code to see the other
> possible benefits it might provide, then that's where we differ.
I look at jQuery reviews and I am appalled at the utter incompetence that
must be at work there at the jQuery team (if there is such a thing). I look
at jQuery code myself, and the reaction is not much different. I look at
jQuery extensions, and I wonder how anybody can *maintain* that illegible
stuff. I look at code that uses jQuery extensions (ohh, the *display* looks
fine on *this* machine!) and wonder what the heck they were smoking,
replacing what could have been a one-liner that works everywhere with N
lines of gobbledygook that by definition works only in a small subset of
UAs. And then I dare call it junk, inside and outside.
>> That argument would be sound if there was no alternative to using jQuery.
>> But there is.
>
> I would genuinely be interested in hearing what you feel the
> alternatives are and why they are the "better" choice in different
> situations.
The alternatives are, among others, to have methods passed an object
reference instead of using a universal wrapper method, to do feature-testing
instead of browser-sniffing or object inference, to write branching code
only when necessary, to modify CSS declarations or to add CSS instead of
finding elements by selector and modifying their style each, and to use
smart event-bubbling instead of mindless listener-adding to each and every
possible element.
HTH
PointedEars
David Mark
> On Apr 2, 10:57 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > > I do not know of a better alternative. If one were available, I would
> > > probably use and recommend it and drop jQuery.
> > But the alternatives have been named here and elsewhere a hundred times or
> > more, and you have refused to consider them to date.
>
> I know there are alternatives. But so far none of them have been
> "better".
So lets look at your "fadeOut" question.
Alternative A is to dig up "setOpacity" from the archive. I assume
you know how to use window.setInterval. If not, it is well documented
and well supported. :)
Alternative Z is to download 50K of gobbledygook called jQuery, dump
it on your sites and pray.
Now, for example, when you find out that you can do a fade out (as
well as other animations) in WebKit with virtually no script at all?
I guess *you* wait for an upgrade, swap out the whole script and re-
test *everything*.
Strange that you would do such a thing. At the rate jQuery is going,
I think you'll be waiting quite a while for that particular
improvement (they will need to fix attr first!)
>
> If you're judging purely by code quality or robustness, then sure.
I'm judging jQuery by the inconceivable level of misunderstanding in
its *latest* incarnation. It is nowhere near competent (or consistent
across browsers or its own releases), let alone robust. Using it can
do nothing but confuse you further and that is clear from your
comments (or lack thereof) regarding the attr method. It's been a
year and a half since I pointed out that very critical and
unquestionably broken code. And Resig doesn't seem to understand
either.
> There are better alternatives. But that is ignoring other factors such
> as:
> a) Documentation
Read the documentation for the attr method.
> b) Support
Read the support attempt for the attr method (from last week!)
> c) Examples
Read the examples that use the attr method (virtually all of them.)
> d) Simplicity of bringing new developers into the code without
> learning a new API
To this day, *you* do not understand the API. Still waiting for your
explanation of what the attr method is supposed to do. Not what it
does, but what you think it is supposed to do. Can you explain that
in terms that *anyone* will understand? Getting and setting DOM
properties was pretty simple to begin with. ;)
> e) Testing
It would take some pretty poor unit tests to allow that attr method to
exist in its current shape (more or less) for *three years*. You
can't write a unit test for something you don't understand.
> f) Continuous improvement
Continuous do-overs. I've got scripts from the year 2000 that are
still in production, have never been touched and, yes, they have fade
effects. :)
> g) Development time/speed
You can't develop anything with an API you don't understand. There's
no way you can be confident in anything you have ever built with
jQuery (unless you are irretrievably stupid.) And upgrading, re-
testing every time Resig spots another groaner is a supreme waste of
time and money.
> h) Cost
See previous.
> i) "Approved For Use" by IT/Mgmt
Not if I've ever been in your shop. Think they have any idea on their
own?
>
> When I factor in all those things, other alternatives become less
> appealing. You can argue all you want that it shouldn't be this way,
> but it IS, and currently using jQuery is the best decision in some
> situations. In other situations, when I consider all the factors, it
> is not the best decision. It depends.
Shut up.
>
> > > I have no particular attachment to jQuery, personally.
> > I wouldn't be so sure about that.
>
> Oh, I'm sure. I've been very critical of it, even in personal email
> conversations with Mr. Resig. I'm pretty sure he doesn't much care for
> me, but that's okay. ;)
Shut up.
>
> > The way you unwaveringly *defend* this
> > junk, which maybe beautifully-looking junk (to me it reads outside as the
> > junk that it is inside, but there's no accounting for taste), but *junk*
> > nonetheless, speaks of a very deep personal attachment to it.
>
> If you cannot look beyond the "junkiness" of the code to see the other
> possible benefits it might provide, then that's where we differ.
>
> > That argument would be sound if there was no alternative to using jQuery.
> > But there is.
>
> I would genuinely be interested in hearing what you feel the
> alternatives are and why they are the "better" choice in different
> situations.
And shut up. I've heard enough of your jQuery-induced histrionics for
one lifetime.
Matt Kruse
wrote:
> OMG, are you living in luserland after all? *You* are the developer, the
> expert (in your team, I hope), who apparently needs all that stuff jQuery
> offers; are you not capable of providing something better than jQuery that
> does the same, after all this time and all these discussions?
Typical. You can only think in terms of your environment and your
situation, and you assume that everyone else's is the same. I'm a
reasonably intelligent guy. I know how to balance conflicting needs to
arrive at the best possible solution, even if it's not ideal. If there
was an easier, more obvious solution, don't you think I would go for
it? Or do you really think I'm so in love with jQuery that I'll stick
to it no matter what? On the contrary, I've chosen NOT to use it in
some projects because it wasn't the best choice, and I've actually
REMOVED it from projects (replaced with POJS) because it was a
performance problem. It all depends.
> > When I factor in all those things, other alternatives become less
> > appealing. You can argue all you want that it shouldn't be this way,
> > but it IS,
> Only because *you* make it so. If you state your case and tell the suits
> that what they want is an incredibly bad idea, if you explain why, and if
> you offer alternatives to them, maybe some more expensive now but also more
> profitable in the mid-term or long-term, they will listen. BTDT.
Oh, of course. I'll just tell it to the suits! Easy! Genius! (Do you
think we all work in a Dilbert office? heh)
> The alternatives are, among others, to have methods passed an object
> reference instead of using a universal wrapper method, to do feature-testing
> instead of browser-sniffing or object inference, to write branching code
> only when necessary, to modify CSS declarations or to add CSS instead of
> finding elements by selector and modifying their style each, and to use
> smart event-bubbling instead of mindless listener-adding to each and every
> possible element.
Okay, those are alternative programming tactics. And obvious. But none
of them are _jQuery_ alternatives. Nobody chooses jQuery because of
its internal technical genius (I hope). They choose it because it
offers a convenient API and a layer of abstraction over things they
don't want to spend hours figuring out and creating - and does so in a
finished, documented, tested, and supported package. That matters. An
"alternative" to jQuery must address those needs. That is what is
lacking from so many arguments that recommend "ditching" jQuery but
suggest no good alternatives that offer the things that made people
choose jQuery to begin with.
Now, do you have a packaged library ready to distribute to a team of
20, half of them in India, which incorporates these concepts? Is it
documented with examples, so they can get help if needed? Is it
tested? How much time do I have to allocate to teach each person how
to use the library? When the project gets handed off to another team,
how much cost will be involved with them learning the API and
debugging? Oh, and what's the licensing on this code? Has it been
approved for use in internal apps by IT, or do I have to begin the
approval process?
No? See, then you don't have an alternative.
Matt Kruse
Matt Kruse
> And shut up. I've heard enough of your jQuery-induced histrionics for
> one lifetime.
Indeed, and I have grown tired of your childish comedy routine.
"Look at this, it fails for some users during the day! You don't know
why? You're stupid."
"What would happen if I did X with the attr() method? You don't know?
And you use this junk? You're stupid."
"Can you describe what this code is intended to do? No? You're
stupid."
"Look at these idiots in this thread. I know what they're doing wrong,
but they don't deserve the answer. They're stupid."
I've tried to have an intelligent exchange with you, but it is
obviously a waste of time. This is why jQuery is successful. Because
people like you - who may actually have technical knowledge and
recommendations that would be helpful - are often complete assholes
and it's just easier to ignore you.
Matt Kruse
ps - Good luck with your book.
Thomas Allen
> Indeed, and I have grown tired of your childish comedy routine.
>
> "Look at this, it fails for some users during the day! You don't know
> why? You're stupid."
> "What would happen if I did X with the attr() method? You don't know?
> And you use this junk? You're stupid."
> "Can you describe what this code is intended to do? No? You're
> stupid."
> "Look at these idiots in this thread. I know what they're doing wrong,
> but they don't deserve the answer. They're stupid."
You forgot the parts where he called you a "buffoon."
Thomas
David Mark
> On Apr 2, 2:21 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > And shut up. I've heard enough of your jQuery-induced histrionics for
> > one lifetime.
>
> Indeed, and I have grown tired of your childish comedy routine.
>
> "Look at this, it fails for some users during the day! You don't know
> why? You're stupid."
Never said that at all. This is what I said:
"LOL. If you can't figure *that* out, then perhaps you need to take a
step back and reevaluate your position."
I'll go a step further and state for the record that you *are* stupid
if you can't figure that out. You only had to analyze one line of
code for one browser.
> "What would happen if I did X with the attr() method? You don't know?
> And you use this junk? You're stupid."
First you said you don't use it, but that was naive as jQuery uses it
internally. Then I asked you to explain why this method is simpler or
more concise or easier to understand than getting and setting DOM
properties. That explanation is still pending.
These work the same in all known browsers and likely always will:
el.src;
el.href;
el.data;
el.longDesc
el.onclick;
Go ahead and "cheat" if you want (analyze the code, which shouldn't be
necessary for a simple API and is impossible to expect from a
neophyte) and give me the jQuery equivalent. This is hardly
esoterica.
Bonus:
Which of these is correct in jQuery (again, go ahead and "cheat.")
$(el).attr('onclick', 'alert("test");');
$(el).attr('onclick', function() { alert("test"); });
I know you are big on gathering empirical data. I suggest you get out
the graph paper, multiple colored markers, etc. and dig in for a long
night. Never mind the code, look at the *results*. Or just admit that
you were a complete prat for recommending something you don't know how
to use and certainly don't understand.
Or you could just look at the code. As you stated, it ain't rocket
science (it's not *any* sort of science.) Of course, that begs the
question as to why it hasn't been fixed in three years, despite my
handing you the solution on a silver platter.
For an essay, explain why most HTML applications do not need the get/
setAttribute methods at all. Very strange that jQuery relies on them
in some situations and not others and that those situations appear to
be based on random observations and misconceptions.
> "Can you describe what this code is intended to do? No? You're
> stupid."
Never said that either. But if you mean the attr method, I would say
it takes a very foolish individual to rely on something they can't
explain. I don't mean explain the code, explain the *rules*. See the
jQuery documentation for a completely vague and confused account of
what somebody thinks it does.
> "Look at these idiots in this thread. I know what they're doing wrong,
> but they don't deserve the answer. They're stupid."
Don't be an idiot. I reported this issue to John Resig himself in the
fall of 2007. The fact that people are still stumbling over it today
is not my fault. I am not even a member of that group. Why didn't
you chime in?
>
> I've tried to have an intelligent exchange with you, but it is
> obviously a waste of time. This is why jQuery is successful.
For some reason I'm reminded of Ted Stryker from "Airplane." He's
up! No, he's down! He's all over the place. What an asshole!
> Because
> people like you - who may actually have technical knowledge and
> recommendations that would be helpful - are often complete assholes
> and it's just easier to ignore you.
Then stick your head back in the sand. You are the one who asked me
for help. Now you don't want it. See above.
David Mark
Nobody likes a snitch, townie.
Thomas Allen
Nobody likes an insult, socially inept dipshit.
Thomas
David Mark
Yeah, you should have thought of that before you blew in here and
insulted me (perhaps you forgot about that.) I see from another
thread that you now want my advice on "Javascript libraries." Don't
hold your breath.
Thomas Allen
It's not your advice I'm looking for, but a cogent opinion. It's funny
that you tell me to "search for it" when you're happy to repeat your
jQuery.fn.attr complaint dozens of times. It's funnier that somebody
who frequently harkens back to others' past posts would call another a
"snitch" for doing the same.
And let the record show that I did not insult _you_ but accused you of
committing "douchebaggery" which I maintain you were. Person !=
Actions...
Thomas
David Mark
> On Apr 2, 5:43 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Apr 2, 5:22 pm, Thomas Allen <thomasmal...@gmail.com> wrote:
>
> > > On Apr 2, 4:56 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > On Apr 2, 4:33 pm, Thomas Allen <thomasmal...@gmail.com> wrote:
>
> > > > > On Apr 2, 4:24 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>
> > > > > > Indeed, and I have grown tired of your childish comedy routine.
>
> > > > > > "Look at this, it fails for some users during the day! You don't know
> > > > > > why? You're stupid."
> > > > > > "What would happen if I did X with the attr() method? You don't know?
> > > > > > And you use this junk? You're stupid."
> > > > > > "Can you describe what this code is intended to do? No? You're
> > > > > > stupid."
> > > > > > "Look at these idiots in this thread. I know what they're doing wrong,
> > > > > > but they don't deserve the answer. They're stupid."
>
> > > > > You forgot the parts where he called you a "buffoon."
>
> > > > Nobody likes a snitch, townie.
>
> > > Nobody likes an insult, socially inept dipshit.
>
> > Yeah, you should have thought of that before you blew in here and
> > insulted me (perhaps you forgot about that.) I see from another
> > thread that you now want my advice on "Javascript libraries." Don't
> > hold your breath.
>
> It's not your advice I'm looking for, but a cogent opinion.
I don't think you'd know one if you saw one.
> It's funny
> that you tell me to "search for it" when you're happy to repeat your
> jQuery.fn.attr complaint dozens of times. It's funnier that somebody
People keep asking. :)
> who frequently harkens back to others' past posts would call another a
> "snitch" for doing the same.
Rubbish, I virtually *never* refer to the past postings of others,
though citing postings (or other articles) to prove a point is hardly
tantamount to snitching.
>
> And let the record show that I did not insult _you_ but accused you of
> committing "douchebaggery" which I maintain you were. Person !=
> Actions...
Yes, I know. It is your favorite word. Means anything that makes you
feel less confident in your abilities.
You should realize that houses of cards tend to collapse very suddenly
and completely. As a jQuery "programmer", I see a homeless shelter in
your future.
Thomas Allen
No, JavaScript is not even remotely my specialty, which is why I come
here asking for help. It's also why I rely on a JavaScript library (I
arrived at jQuery after trying MooTools). I'm mainly a Python/PHP dev
and I've never had trouble finding work.
But I do know my way around the language well enough to help with
easier questions, which is why I'll still be around here helping
people out with those (so that they can get some help without the BS
and condescension).
Thomas
David Mark
That much is apparent. Do you know how to get and set properties? If
so, you are ahead of all of the other jQuery developers.
> which is why I come
> here asking for help.
You should tread lightly then (and sure as hell not on me!)
> It's also why I rely on a JavaScript library (I
> arrived at jQuery after trying MooTools). I'm mainly a
Of course. But you have no way to judge said library or the
alternatives. You are throwing darts at a map, hoping to hit Shangri-
la.
> Python/PHP dev
> and I've never had trouble finding work.
Who asked you? I sure as hell wouldn't hire a puerile pissant like
yourself, but there is no accounting for taste.
>
> But I do know my way around the language well enough to help with
> easier questions
No, you don't. Do you need citations?
> which is why I'll still be around here helping
> people out with those (so that they can get some help without the BS
> and condescension).
Good luck with that!
Thomas Allen
David Mark
> On Apr 2, 6:29 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Who asked you?
>
> You did.
In a pig's ear.
[snip]
Thomas Allen
> yourself, but there is no accounting for taste.
Damn shame. Looks like business is booming.
http://www.cinsoft.net/
"Directory Listing Denied
This Virtual Directory does not allow contents to be listed."
BTW, spiffy library. And the world's beating a path to your door:
http://groups.google.com/group/my-library-general-discussion/
Thomas
David Mark
> On Apr 2, 6:29 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Who asked you? I sure as hell wouldn't hire a puerile pissant like
> > yourself, but there is no accounting for taste.
>
> Damn shame. Looks like business is booming.http://www.cinsoft.net/
That is a redirect farm you loopy lunatic.
>
> "Directory Listing Denied
> This Virtual Directory does not allow contents to be listed."
Exactly. That URI is not advertised for a reason.
>
> BTW, spiffy library. And the world's beating a path to your door:http://groups.google.com/group/my-library-general-discussion/
You have no idea.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
> >> David Mark writes:
> >>> Thomas Allen wrote:
> >> Anyway, I wouldn't use "arguments.length", because it makes the
> >> Javascript engine need to create the arguments object.
> >
>
> I would avoid that, too, for the same reason. Using |arguments|
> prevents
> an implementation from making an optimization.
| 10.1.8 Arguments Object
|
| When control enters an execution context for
| function code, an arguments object is created
| as follows: [...]
Did you get that now? There can be no real optimization here unless the
implementation would forego standards compliance. And I (and others)
have already demonstrated that because of the dynamic nature of the
language it is virtually impossible for an implementation to determine
use or non-use of the ‘arguments' object before execution.
> > That the arguments object is not created when not used is an
> > unfounded
> > assumption, or rather wishful thinking on your part in order to
> > support your
> > argument. The ECMAScript Specification, Edition 3 Final, widely
> > implemented
> > as opposed to the ES 4+(!) dreaming, says otherwise.
>
> An ECMAScript implementation guarantees behavior.
Nonsense. The Specification could not be clearer in that regard, and
implementors are well-advised not to try any "optimizations" here.
(So much for debunking
> an "unfounded assuption"). If a function body does not make a
> reference
> to |arguments| or |eval|, an implementation could create an optimized
> call for that function.
The resources that would need to be invested to determine before
execution if there really is an reference to the arguments object are
better spent elsewhere.
> Implementations may make a static analysis of the function to
> determine
> if an optimized call can be performed and perform such optimized call,
>
> if the side effects of such call would not be observable
Nonsense.
> It has been demonstrated that implementations actually seem to do
> this.
Then their implementors are at fault, and the change should be reverted,
better sooner than too late.
> However, it the question is to determine if a function foo:-
>
> function foo(x){
> alert(x === undefined);
> }
>
> - has been passed an argument, as in:-
>
> foo(undefined)
>
> - as opposed to -
>
> foo()
>
> - would be to check the arguments object.
>
> 10.1.3 guarantees that missing parameters get value |undefined|.
No, it doesn't:
undefined = "foo";
We've been over this. There is one bullet-proof way to determine if an
argument has been passed or not: checking arguments.length.
> | If the caller supplies fewer parameter values than there are formal
> | parameters, the extra formal parameters have value undefined.
undefined != ‘undefined’
or, if you prefer the less ambiguous version:
typeof undefined != "undefined"
> > So much for being helpful.
>
> This has been discussed on here in detail before.
But apparently you haven't been paying attention then either.
PointedEars
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
> [...]
> >> should know the intricacies of Javascript engines quite well and is
> > >
> >> probably stating arguments rather than "wishfully thinking".
> >
> > Of that particular ECMAScript implementation for sure. There is no
> > such
> > thing as a "Javascript engine".
>
> Aren't those interchangeable?
Are you kidding? Is there an error in the Matrix or is it not
comprehensive enough (the latter issue is being addressed, and hopefully
fixed soon.)
> I see both WebKit [1] and Mozilla [2]
> calling their "ECMAScript implementations" exactly that - "Javascript
> engines".
Two wrongs also make no right here.
> [...]
> >> I don't have time to search through V8, but have all the reasons to
> > >
> >> trust him.
> >
> > Thanks. So that would be JSCore and V8; about, say, 5% of the
> > market? What
> > difference does it make for past ECMAScript implementations still in
> > use,
> > and current, let alone future ones?
>
> No difference of course. The point was to merely find out whether
> *any*
> of the currently existing implementations perform the optimization,
> and
> to see whether this is a "wishful thinking" on our part or is an
> actual
> fact.
>
> Now we know they do.
But that means nothing, for they could as well be wrong (and I think
they are).
> Just to speculate:
Making decisions based on pure speculation (let's call that wishful
thinking instead, shall we?) is probably the third blunder.
> I think such optimizations will matter more in the near future,
> although
> given the tremendous rise in execution speed of current "ECMAScript
> implementations", the difference might not be worth attention.
Given the tiny amount of memory and the tiny delay in run-time that it
takes to create the arguments object, as opposed to the amount of memory
and run-time that it would take to find out for sure if the object is
needed or not, it does not make sense to attempt an optimization here in
the first place.
PointedEars
Thomas Allen
Your site is so well unadvertised that it's invisible to Google. Still
in "stealth mode" after six years? What a joke. And for all your
insults, I expected work more impressive than this:
http://www.cinsoft.net/hartkelaw/index.html
I mean, couldn't you sell the guy a domain?
David Mark
> On Apr 2, 7:13 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Apr 2, 7:02 pm, Thomas Allen <thomasmal...@gmail.com> wrote:
>
> > > On Apr 2, 6:29 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > > Who asked you? I sure as hell wouldn't hire a puerile pissant like
> > > > yourself, but there is no accounting for taste.
>
> > > Damn shame. Looks like business is booming.http://www.cinsoft.net/
>
> > That is a redirect farm you loopy lunatic.
>
> > > "Directory Listing Denied
> > > This Virtual Directory does not allow contents to be listed."
>
> > Exactly. That URI is not advertised for a reason.
>
> > > BTW, spiffy library. And the world's beating a path to your door:http://groups.google.com/group/my-library-general-discussion/
>
> > You have no idea.
>
> Your site is so well unadvertised that it's invisible to Google. Still
Hello? McFly? It's not a site. It's a domain and it's none of your
business anyway (that's why it isn't advertised.)
> in "stealth mode" after six years? What a joke. And for all your
> insults, I expected work more impressive than this:
Hmmm. Type "browser scripting library" into Google (or whatever) and
see what you come up with. That is the only site on the domain and
Google sure seems to know about it. :)
>
> http://www.cinsoft.net/hartkelaw/index.html
>
> I mean, couldn't you sell the guy a domain?
Couldn't you go intercourse your mother?
http://www.hartkelaw.net/hartkelaw/index.html
Again, none of your business at all (unless you need a good lawyer.)
Thomas Allen
> Couldn't you go intercourse your mother?
Eloquent indeed. How about you go see yours? She's right upstairs, I'm
sure. Now you see how it feels: You tell me that I'm unhirable, and
I'll _show_ that you are (not that anybody would want your attitude on
their team). I mean, if that's your work experience going back to
2002, that's pretty sad:
http://www.google.com/search?hl=en&as_q=&as_epq=&as_oq=&as_eq=&num=10&lr=&as_filetype=&ft=i&as_sitesearch=www.cinsoft.net&as_qdr=all&as_rights=&as_occt=any&cr=&as_nlo=&as_nhi=&safe=off
Anyway, enough time wasting. I have to wrap up changes on a website
since the client's board will be meeting tomorrow to review it. And it
has *gasp* jQuery installed! I'm sure I'll lose the room when I hear
that.
Thomas
David Mark
> On Apr 2, 7:41 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Couldn't you go intercourse your mother?
>
> Eloquent indeed. How about you go see yours? She's right upstairs, I'm
You wouldn't make a very good detective either.
> sure. Now you see how it feels: You tell me that I'm unhirable, and
> I'll _show_ that you are (not that anybody would want your attitude on
> their team). I mean, if that's your work experience going back to
> 2002, that's pretty sad:
http://www.google.com/search?hl=en&as_q=&as_epq=&as_oq=&as_eq=&num=10...
I must have missed Sixty Minutes.
>
> Anyway, enough time wasting. I have to wrap up changes on a website
Like posting links to my mock-ups?
> since the client's board will be meeting tomorrow to review it. And it
> has *gasp* jQuery installed! I'm sure I'll lose the room when I hear
> that.
>
I think the client, board and meeting are all in your head.