JS strangeness
Pink Pig
since I just joined this group and haven't attempted to search the
archives.)
I have a page under construction which uses jQuery and is fairly
massive. When I run it locally under Firefox, everything works fine,
but when I run it on the host site, I frequently run into difficulties
of the following type. I have a $(document).ready() function that
references variables and elements defined either in other JS scripts
(inline), or in the HTML. Sometimes, but not always, a reference to
one of these variables or elements resolves to a null pointer, which
aborts the execution of my $(document).ready() function and causes FF
to get hung up in the wrong place. For example, I have a JS variable
called 'calimg', which is supposed to be a string containing the URL
of an image file, and if I look at the source, that is how it is
defined, in a script that is placed before the script containing the $
(document).ready() function. But often, Firebug reports that the
variable 'calimg' is not defined when the $(document).ready() function
runs. What is causing this, and what can I do about it?
Thomas 'PointedEars' Lahn
> [...] But often, Firebug reports that the variable 'calimg' is not
> defined when the $(document).ready() function runs. What is causing this,
> and what can I do about it?
Get a minimum clue and don't rely on junk like jQuery.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Pink Pig
wrote:
This is really not a helpful response. You might at least point me to
the appropriate section of this massive document.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Pink Pig wrote:
>>> [...] But often, Firebug reports that the variable 'calimg' is not
>>> defined when the $(document).ready() function runs. What is causing this,
>>> and what can I do about it?
>> Get a minimum clue and don't rely on junk like jQuery.
>>
>> <http://jibbering.com/faq/>
>
> This is really not a helpful response. You might at least point me to
> the appropriate section of this massive document.
Try the section about how to post properly; it will lead to everything else.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Pink Pig
wrote:
> Try the section about how to post properly; it will lead to everything else.
of which appears to be relevant to the question that I asked. If you
know what the answer is, why don't you just tell me?
David Mark
> (I don't know if this question has been asked and answered many times,
> since I just joined this group and haven't attempted to search the
> archives.)
Seems like that would be the best time to search the archives.
>
> I have a page under construction which uses jQuery and is fairly
Oops.
> massive. When I run it locally under Firefox, everything works fine,
Or so it might seem.
> but when I run it on the host site, I frequently run into difficulties
> of the following type. I have a $(document).ready() function that
> references variables and elements defined either in other JS scripts
> (inline), or in the HTML. Sometimes, but not always, a reference to
> one of these variables or elements resolves to a null pointer, which
> aborts the execution of my $(document).ready() function and causes FF
> to get hung up in the wrong place. For example, I have a JS variable
> called 'calimg', which is supposed to be a string containing the URL
> of an image file, and if I look at the source, that is how it is
> defined, in a script that is placed before the script containing the $
> (document).ready() function. But often, Firebug reports that the
> variable 'calimg' is not defined when the $(document).ready() function
> runs. What is causing this, and what can I do about it?
Stop using jQuery. If you plan to deploy a "massive" Web application,
it would seem a good time to learn JavaScript. The people who wrote
jQuery never bothered and now you are compounding their mistakes.
The fact that your app "works" sporadically should come as little
surprise. And the fact that you can't debug your code or articulate
its problems does not bode well for its future.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Try the section about how to post properly; it will lead to everything else.
> Sigh. I know how to post messages, and I've read the entire FAQ, none
> of which appears to be relevant to the question that I asked.
No wonder you are unable to answer your question for yourself if you are
unable to make a text search for "post" and read material while gathering
its meaning.
> If you know what the answer is, why don't you just tell me?
The answer is to get a minimum clue (so that you know what you are doing)
and not to use jQuery (a decision apparent to make when you have that
minimum clue). I believe I have given you that answer already.
Any other answer will either waste my time debugging your code and allow you
to continue using jQuery in the process which would be a Bad Thing, or will
be likely not to be understood by you as you are lacking the minimum clue
required for that.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Pink Pig
OK, there are now two people on my list of programmers I would never
hire. Any other volunteers, or does somebody want to be informative
rather than snide?
Richard Cornford
> (I don't know if this question has been asked
> and answered many times,
Which question? The question you asked, which is effectively ' I have
done something and the outcome is inconsistent', or a question about the
issue that underlies your question?
> since I just joined this group and haven't attempted to
> search the archives.)
That is unlikely to be a popular strategy. Searching and not finding
would not be that unexpected but not searching at all seems lazy.
> I have a page under construction which uses jQuery
Ouch.
> and is fairly massive.
The "do more, write less library" and the results are still "massive"?
> When I run it locally under Firefox, everything works fine,
> but when I run it on the host site, I frequently run into
> difficulties of the following type. I have a $(document).ready()
> function
Do you fully understand what JQuery's ready function does? Having read
its code, I suspect that its authors have not fully understood what it
does and so would be amazed if its documentation made a clear and
accurate statement about what can be expected from it. My expectation of
its actual behaviour would be that it would be inconsistent across
browsers, and certainly likely to be subject to timing issues in page
loading if used in a way that was inappropriate for the behaviour it
actually exhibits.
> that references variables and elements defined either in other
> JS scripts (inline), or in the HTML. Sometimes, but not always,
> a reference to one of these variables or elements resolves to
> a null pointer, which aborts the execution of my
> $(document).ready() function and causes FF to get hung up in the
> wrong place.
So your specific issues are on Firefox? JQuery's - ready - function uses
a - DOMContentLoaded - event on the document (assuming the browser
sniffing does not mess up and misidentify the browser, which is always a
possibility). Firefox's documentation may accurately state the full
implications of using that event.
> For example, I have a JS variable called 'calimg', which is
> supposed to be a string containing the URL of an image file,
> and if I look at the source, that is how it is defined, in a
> script that is placed before the script containing the $
> (document).ready() function. But often, Firebug reports that
> the variable 'calimg' is not defined when the
> $(document).ready() function runs. What is causing this, and
> what can I do about it?
If your implied assertion here is accurate (that you declare a global
variable call - calling - and assign it a value in a global execution
context at a position lexically before a call to - ready - that is also
made in a global execution context) then what you are describing should
be impossible. So your described symptoms and the code details you
describe are mutually contradictory. This is not at all uncommon when
novices ask questions here, and why it can improve the likelihood of a
useful answer if questions are accompanied by a demonstration of the
phenomena being asked about. Though realistically the odds are low that
anyone here would be willing to make the effort to attempt to debug
JQuery code. Sill, you can guarantee that they will not if they cannot
see the code.
Richard.
David Mark
> On Jul 27, 3:44 pm, Pink Pig <b...@grandcentralapartments.com> wrote:
>
> > On Jul 27, 3:20 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> > wrote:> Try the section about how to post properly; it will lead to everything else.
>
> > Sigh. I know how to post messages, and I've read the entire FAQ, none
Do you?!
> > of which appears to be relevant to the question that I asked. If you
> > know what the answer is, why don't you just tell me?
>
> OK, there are now two people on my list of programmers I would never
Thomas and yourself I presume. If in fact you meant to reply to me,
you needn't bother. I officially remove my name from consideration
for all present and future "Pink Pig" enterprises. I hate pinheads
who post vague "questions" and then cry when they don't get answered.
> hire. Any other volunteers, or does somebody want to be informative
> rather than snide?
What part of "learn JavaScript" was uninformative. You also got the
very informative advice to avoid jQuery. Hopefully you weren't too
far into your "massive" app to change course. Good luck!
Pink Pig
wrote:
> Pink Pig" wrote:
> > (I don't know if this question has been asked
> > and answered many times,
>
> Which question? The question you asked, which is effectively ' I have
> done something and the outcome is inconsistent', or a question about the
> issue that underlies your question?
Cheap shot #1.
>
> > since I just joined this group and haven't attempted to
> > search the archives.)
>
> That is unlikely to be a popular strategy. Searching and not finding
> would not be that unexpected but not searching at all seems lazy.
Cheap shot #2.
>
> > I have a page under construction which uses jQuery
>
> Ouch.
>
> > and is fairly massive.
>
> The "do more, write less library" and the results are still "massive"?
Cheap shot #3. Is that all you guys are good for?
>
> > When I run it locally under Firefox, everything works fine,
> > but when I run it on the host site, I frequently run into
> > difficulties of the following type. I have a $(document).ready()
> > function
>
> Do you fully understand what JQuery's ready function does? Having read
> its code, I suspect that its authors have not fully understood what it
> does and so would be amazed if its documentation made a clear and
> accurate statement about what can be expected from it. My expectation of
> its actual behaviour would be that it would be inconsistent across
> browsers, and certainly likely to be subject to timing issues in page
> loading if used in a way that was inappropriate for the behaviour it
> actually exhibits.
My expectation, on the other hand, is that there may be bugs in it
that can be worked around one way or another. I do not look down my
nose at people who are trying to clean up the mess created by the
designers of JS -- I wish them well.
>
> > that references variables and elements defined either in other
> > JS scripts (inline), or in the HTML. Sometimes, but not always,
> > a reference to one of these variables or elements resolves to
> > a null pointer, which aborts the execution of my
> > $(document).ready() function and causes FF to get hung up in the
> > wrong place.
>
> So your specific issues are on Firefox? JQuery's - ready - function uses
> a - DOMContentLoaded - event on the document (assuming the browser
> sniffing does not mess up and misidentify the browser, which is always a
> possibility). Firefox's documentation may accurately state the full
> implications of using that event.
My specific issue at the moment is in the relationship between FF and
jQuery. I expect that I will have other issues in the future, but I
won't trouble you with them. You haven't yet told me anything I didn't
already know.
>
> > For example, I have a JS variable called 'calimg', which is
> > supposed to be a string containing the URL of an image file,
> > and if I look at the source, that is how it is defined, in a
> > script that is placed before the script containing the $
> > (document).ready() function. But often, Firebug reports that
> > the variable 'calimg' is not defined when the
> > $(document).ready() function runs. What is causing this, and
> > what can I do about it?
>
> If your implied assertion here is accurate (that you declare a global
> variable call - calling - and assign it a value in a global execution
> context at a position lexically before a call to - ready - that is also
> made in a global execution context) then what you are describing should
> be impossible. So your described symptoms and the code details you
> describe are mutually contradictory. This is not at all uncommon when
> novices ask questions here, and why it can improve the likelihood of a
> useful answer if questions are accompanied by a demonstration of the
> phenomena being asked about.
a) I am not a novice. I was most likely programming before you were
born.
b) I was very careful to describe exactly what was going on, and how
the code was written. I've looked it over, and it's accurate.
c) I did not choose jQuery, and I am not free to just throw it away.
> Though realistically the odds are low that
> anyone here would be willing to make the effort to attempt to debug
> JQuery code. Sill, you can guarantee that they will not if they cannot
> see the code.
I gathered as much. I've also noticed that no one has pointed me to a
place where the question might be answered.
David Mark
> On Jul 27, 5:53 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
>
> > Pink Pig" wrote:
> > > (I don't know if this question has been asked
> > > and answered many times,
>
> > Which question? The question you asked, which is effectively ' I have
> > done something and the outcome is inconsistent', or a question about the
> > issue that underlies your question?
>
> Cheap shot #1.
>
Looks like a reasonable enough question to me.
>
>
> > > since I just joined this group and haven't attempted to
> > > search the archives.)
>
> > That is unlikely to be a popular strategy. Searching and not finding
> > would not be that unexpected but not searching at all seems lazy.
>
> Cheap shot #2.
No. It does seem lazy.
>
>
>
> > > I have a page under construction which uses jQuery
>
> > Ouch.
>
> > > and is fairly massive.
>
> > The "do more, write less library" and the results are still "massive"?
>
> Cheap shot #3. Is that all you guys are good for?
You really should ask for a refund.
>
>
>
> > > When I run it locally under Firefox, everything works fine,
> > > but when I run it on the host site, I frequently run into
> > > difficulties of the following type. I have a $(document).ready()
> > > function
>
> > Do you fully understand what JQuery's ready function does? Having read
> > its code, I suspect that its authors have not fully understood what it
> > does and so would be amazed if its documentation made a clear and
> > accurate statement about what can be expected from it. My expectation of
> > its actual behaviour would be that it would be inconsistent across
> > browsers, and certainly likely to be subject to timing issues in page
> > loading if used in a way that was inappropriate for the behaviour it
> > actually exhibits.
>
> My expectation, on the other hand, is that there may be bugs in it
Fair expectation. There are.
> that can be worked around one way or another. I do not look down my
> nose at people who are trying to clean up the mess created by the
> designers of JS -- I wish them well.
You seem confused.
>
>
>
> > > that references variables and elements defined either in other
> > > JS scripts (inline), or in the HTML. Sometimes, but not always,
> > > a reference to one of these variables or elements resolves to
> > > a null pointer, which aborts the execution of my
> > > $(document).ready() function and causes FF to get hung up in the
> > > wrong place.
>
> > So your specific issues are on Firefox? JQuery's - ready - function uses
> > a - DOMContentLoaded - event on the document (assuming the browser
> > sniffing does not mess up and misidentify the browser, which is always a
> > possibility). Firefox's documentation may accurately state the full
> > implications of using that event.
>
> My specific issue at the moment is in the relationship between FF and
> jQuery. I expect that I will have other issues in the future, but I
The relationship is that Mozilla employs the author of jQuery, yet the
library still resorts to browser sniffing to work in FireFox. Seems
like an issue for them at the present. As for your future issues, I
really can't comment.
> won't trouble you with them. You haven't yet told me anything I didn't
> already know.
Now you are posturing for the one person who actually tried to help.
I imagine that is the last help you will get here. Happily, you've
used an alias, so you can just start over as s pig of a different
color.
>
>
>
>
>
> > > For example, I have a JS variable called 'calimg', which is
> > > supposed to be a string containing the URL of an image file,
> > > and if I look at the source, that is how it is defined, in a
> > > script that is placed before the script containing the $
> > > (document).ready() function. But often, Firebug reports that
> > > the variable 'calimg' is not defined when the
> > > $(document).ready() function runs. What is causing this, and
> > > what can I do about it?
>
> > If your implied assertion here is accurate (that you declare a global
> > variable call - calling - and assign it a value in a global execution
> > context at a position lexically before a call to - ready - that is also
> > made in a global execution context) then what you are describing should
> > be impossible. So your described symptoms and the code details you
> > describe are mutually contradictory. This is not at all uncommon when
> > novices ask questions here, and why it can improve the likelihood of a
> > useful answer if questions are accompanied by a demonstration of the
> > phenomena being asked about.
>
> a) I am not a novice. I was most likely programming before you were
> born.
Whether that is true or not, it was almost certainly not JavaScript.
If your plan was to deploy a "massive" public Web application with
jQuery, then yes, you have made a very typical novice mistake. The
longer you rely on other people's mistakes, the less you will learn.
>
> b) I was very careful to describe exactly what was going on, and how
> the code was written. I've looked it over, and it's accurate.
You mean that first post? You forgot to post code or a link to a
sample page. Your ramblings about "null pointers" and "elements
defined either in other JS scripts (inline)", etc. are of little help
(as you were told.)
>
> c) I did not choose jQuery, and I am not free to just throw it away.
Who cares?
>
> > Though realistically the odds are low that
> > anyone here would be willing to make the effort to attempt to debug
> > JQuery code. Sill, you can guarantee that they will not if they cannot
> > see the code.
>
> I gathered as much. I've also noticed that no one has pointed me to a
> place where the question might be answered.
Try Googling "jQuery" or perhaps "jQuery discussion." There's a good
fellow.
Richard Cornford
> On Jul 27, 5:53 pm, Richard Cornford wrote:
>> Pink Pig" wrote:
>>> (I don't know if this question has been asked
>>> and answered many times,
>>
>> Which question? The question you asked, which is effectively 'I
>> have done something and the outcome is inconsistent', or a
>> question about the issue that underlies your question?
>
> Cheap shot #1.
Or an observation that might provide a clue as to how you might get
closer to an getting an answer. Because where you are now is in a hole
and digging as fast as you can.
>>> since I just joined this group and haven't attempted to
>>> search the archives.)
>>
>> That is unlikely to be a popular strategy. Searching and
>> not finding would not be that unexpected but not searching
>> at all seems lazy.
>
> Cheap shot #2.
>
>>> I have a page under construction which uses jQuery
>>
>> Ouch.
>>
>>> and is fairly massive.
>>
>> The "do more, write less library" and the results are still
>> "massive"?
>
> Cheap shot #3. Is that all you guys are good for?
That might be a cheep shot. Marketing BS tends to get my back up. On the
other hand "massive" web applications is something that I do know a
thing or two about, and using JQuery in a "massive" (in my terms) web
application would not be a viable proposition. Its unavoidable execution
overheads would reduce the performance of the applications I work on to
such a degree that they would be unsellable.
<snip>
> My expectation, on the other hand, is that there may be bugs
> in it that can be worked around one way or another.
A much more probably explanation is that you are doing something wrong
as a result of not understanding javascript and/or web browsers very
well and the best solution is to understand what that is and avoid doing
it. Bugs are not an impossibility but they are also not nearly as common
as people's ignorance resulting in their perception of bugs. Bugs in
javascript implementations' handing of variable instantiation and/or
assignment are very few and far between, and most are in IE so can be
dismissed from this question entirely.
> I do not look down my nose at people who are trying to clean
> up the mess created by the designers of JS -- I wish them
> well.
Who implied that the designers of JS made a mess?
<snip>
> My specific issue at the moment is in the relationship between
> FF and jQuery.
How have you eliminated your own JS code from the equation?
> I expect that I will have other issues in the future, but I
> won't trouble you with them. You haven't yet told me anything
> I didn't already know.
You might think so, but you are not behaving as if you did already know
all of the things that I have told you.
<snip>
>> If your implied assertion here is accurate (that you declare
>> a global variable call - calling - and assign it a value in a
>> global execution context at a position lexically before a call
>> to - ready - that is also made in a global execution context)
>> then what you are describing should be impossible. So your
>> described symptoms and the code details you describe are
>> mutually contradictory. This is not at all uncommon when
>> novices ask questions here, and why it can improve the
>> likelihood of a useful answer if questions are accompanied
>> by a demonstration of the phenomena being asked about.
>
> a) I am not a novice. I was most likely programming before
> you were born.
Maybe you have, but how well do you know javascript and/or browser
scripting?
> b) I was very careful to describe exactly what was going on,
> and how the code was written. I've looked it over, and it's
> accurate.
But you ability to describe what is going on is constrained by your
ability to understand what is going on. There is a contradiction in what
you have described, which at minimum means that something is missing
from that description.
> c) I did not choose jQuery, and I am not free to just throw
> it away.
Hard luck.
>> Though realistically the odds are low that
>> anyone here would be willing to make the effort to attempt to debug
>> JQuery code. Sill, you can guarantee that they will not if they
>> cannot
>> see the code.
>
> I gathered as much. I've also noticed that no one has pointed me to a
> place where the question might be answered.
An answer is something that you can get anywhere (ask the next person
you encounter in that street and you likely will get 'an answer'), but
here is where you stand the best chance of getting the answer, though
only if you manage to ask the question in a form that can be answered.
Richard.
jdalton
You might try one of the jQuery mailing lists:
http://docs.jquery.com/Discussion
If you are on twitter.com you can message @jquery for help :)
Also for fun you can read up on the various personalities here:
http://redwing.hutman.net/~mreed/warriorshtm/tirelessrebutter.htm
I hope this helps :D
- JDD
Hamish Campbell
Hey Pink,
The jQuery google group is excellent: http://groups.google.com/group/jquery-en
Plenty of people there (including myself) willing to help out. Try to
post a link to a sample site if possible.
Unfortunately this group can be a little.. old school. I'm pretty sure
that PointedEars et. al. could program JS with an Oscilloscope and a
soldering iron if they really tried. Unfortunately that sword has cut
both ways and they're all but blind to the benefits that jQuery (and
the other hated libraries) bring to real world developers.
Gregor Kofler
> Hey Pink,
>
> The jQuery google group is excellent:
> http://groups.google.com/group/jquery-en
>
> Plenty of people there (including myself) willing to help out. Try to
> post a link to a sample site if possible.
From the information given by the OP, they were equally helpless.
> Unfortunately this group can be a little.. old school.
No. It's just that this group is about JavaScript (and its other brand
names) and not about some libraries written in JS. Just as PHP NGs are
about PHP and not some third party applications written in PHP. And just
as C/C++ NGs are not dealing with the problems of applications written
in these languages. You get the idea?
> they're all but blind to the benefits that jQuery (and
> the other hated libraries) bring to real world developers.
Makes one wonder why all those problems (I suppose I should say
"questions") of such "real world developers" come from...
Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aaron Gray
news:488CCA87...@PointedEars.de...
> Pink Pig wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Pink Pig wrote:
>>>> [...] But often, Firebug reports that the variable 'calimg' is not
>>>> defined when the $(document).ready() function runs. What is causing
>>>> this,
>>>> and what can I do about it?
>>> Get a minimum clue and don't rely on junk like jQuery.
>>>
>>> <http://jibbering.com/faq/>
>>> [...]
>>
>> This is really not a helpful response. You might at least point me to
>> the appropriate section of this massive document.
>
> Try the section about how to post properly; it will lead to everything
> else.
Thomas, You are turning into a bit of a troll. Could you say the same
substance but in a more polite fashon please; as its degrading the list.
Yeah, I never liked jQuery from the start, bumping into $("yyy"). when
reading code was not a very nice experience.
There's another library I have came accross that seems to do the same as
jQuery but seems alot lighterweight and have not heard it mentioned on clj.
Have not used it, but it has four figure version numbers and is up to
2.7.1.1 so it _may_ be a good library.
Anyone checked it out ?
Aaron
Aaron Gray
news:d55594e9-4286-43df...@i76g2000hsf.googlegroups.com...
Yeah, sorry but you have to realize that if everyone is reading your
question thet is X amount of time times Y readers, these whole threads are a
waste of time and should be avoided, best for both sides not to start them
in the first place.
As they say a library is no substitute for knowing whats going on with "bare
metal javascript".
If there are issues with jQuery then take them to one of the jQuery
disscussion lists :-
http://docs.jquery.com/Discussion
comp.lang.javascript is really for Javascript language issues, this is not
alt.lang.javascript and maybe there should really be one.
Aaron
Aaron Gray
news:bbbe665a-ef4a-4fb6...@a6g2000prm.googlegroups.com...
On Jul 28, 5:39 pm, jdalton <John.David.Dal...@gmail.com> wrote:
Unfortunately this group can be a little.. old school. I'm pretty sure
Look at the UseNet groups title "comp.lang.javascript" this sort of thing
would not be tollerated on comp.lang.c or c++. Maybe we need a
comp.lang.javascript.misc or alt.javascript group for this sort of thing ?
Regards,
Aaron
Aaron Gray
news:f638b118-5c97-4e11...@p25g2000hsf.googlegroups.com...
> Also for fun you can read up on the various personalities here:
> http://redwing.hutman.net/~mreed/warriorshtm/tirelessrebutter.htm
No its happening because the 'comp.lang' group is not being used properly.
Anyone can make fun and add a donations page that does not even render
properly.
Aaron
Jorge
> ... could program JS with an Oscilloscope and a
> soldering iron if they really tried.
...and what's wrong with that ?
--Jorge.
Henry
<snip>
> There's another library I have came accross that seems to do the
> same as jQuery but seems alot lighterweight and have not heard it
> mentioned on clj.
>
> http://www.domassistant.com/
>
> Have not used it, but it has four figure version numbers and is
> up to 2.7.1.1 so it _may_ be a good library.
When reviewing John Resig's "Pro JavaScript Techniques" Robert Nyman,
the original author of DOMAssistant, wrote; "I would say that any
JavaScript web developer out there, from intermediate to advanced, can
learn something sincerely valuable from this book.". To read that book
and come to that conclusion does not bode well. It implies he uses a
definition of "advanced" "JavaScript web developer" that does not
involve the possession of the technical understanding that would
result in the reader seeing the many faults and nonsenses in the book
and so dismissing it out of hand as a learning source.
Aaron Gray
>news:60b34fcf-b2ff-418d-ac8f->0e286e...@j22g2000hsf.googlegroups.com...
>On Jul 28, 4:01 pm, Aaron Gray wrote:
>><snip>
>> There's another library I have came accross that seems to do the
>> same as jQuery but seems alot lighterweight and have not heard it
>> mentioned on clj.
>>
>> http://www.domassistant.com/
>>
>> Have not used it, but it has four figure version numbers and is
>> up to 2.7.1.1 so it _may_ be a good library.
><snip>
>
>When reviewing John Resig's "Pro JavaScript Techniques" Robert Nyman,
>the original author of DOMAssistant, wrote; "I would say that any
>JavaScript web developer out there, from intermediate to advanced, can
>learn something sincerely valuable from this book.". To read that book
>and come to that conclusion does not bode well. It implies he uses a
Oh, dear, oh, dear, oh, dear, this does not bode well, your right.
Or maybe he was just glosing over the errors and taking the good bits, some
people are like that and prefer not to emphasize the bad ?
Oh, well I have John's book on order so will see for myself. Just started
reading "Javsscript: The good parts" for some sanity.
Have you used/looked at DOMAssistant at all, has it been used in any medium
scale or large projects at all ?
Regards,
Aaron
Tim Streater
<47446f14-55e2-4d75...@f63g2000hsf.googlegroups.com>,
Jorge <jo...@jorgechamorro.com> wrote:
Personally I use a bar magnet and a magnifying glass. Saves amazing
amounts of CPU.
Thomas 'PointedEars' Lahn
> When reviewing John Resig's "Pro JavaScript Techniques" Robert Nyman,
> the original author of DOMAssistant, wrote; "I would say that any
> JavaScript web developer out there, from intermediate to advanced, can
> learn something sincerely valuable from this book.". To read that book
Well, there is certainly one valuable thing that can be learned from this
book: how not to write one ;-)
Jorge
> In article
> <47446f14-55e2-4d75-9db3-2e23ffc67...@f63g2000hsf.googlegroups.com>,
Oh, yes, the magnifying glass changed my life. But what's the magnet
for ?
--Jorge.
Gregor Kofler
> There's another library I have came accross that seems to do the same as
> jQuery but seems alot lighterweight and have not heard it mentioned on clj.
>
> http://www.domassistant.com/
>
> Have not used it, but it has four figure version numbers and is up to
> 2.7.1.1 so it _may_ be a good library.
Dunno...
line 6:
var isIE = /*@cc_on!@*/false;
line 1330:
if (/KHTML|WebKit|iCab/i.test(navigator.userAgent)) {
DOMLoadTimer = setInterval(function () {
if (/loaded|complete/i.test(document.readyState)) {
DOMHasLoaded();
clearInterval(DOMLoadTimer);
}
}, 10);
}
And why would one want to do something like that:
window.addEvent = this.addEvent;
window.removeEvent = this.removeEvent;
Dr J R Stockton
g2000hsc.googlegroups.com>, Sun, 27 Jul 2008 12:18:24, Pink Pig
<bi...@grandcentralapartments.com> posted:
>On Jul 27, 2:51 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
>wrote:
>> Pink Pig wrote:
>> > [...] But often, Firebug reports that the variable 'calimg' is not
>> PointedEars
>> --
>This is really not a helpful response. You might at least point me to
>the appropriate section of this massive document.
if you had prudently read the newsgroup before posting, you would have
known what to expect from Lahn.
--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Hamish Campbell
> > > ... could program JS with an Oscilloscope and a
> > > soldering iron if they really tried.
> >
> > ...and what's wrong with that ?
>
> Personally I use a bar magnet and a magnifying glass. Saves amazing
> amounts of CPU.
Hehe. Yeah, my point was that there are serious experts in this forum,
but few programmers - even good ones - have the time/inclination/
ability to delve into the inner workings of JS (and even fewer get to
the point where they seem to be able to quote the spec at will!).
And hey, an accessible library like jQuery is [hopefully] a good entry
point for someone who will later learn *ahem* real JS.
Meanwhile, I'm fixing basic PHP/SQL injection issues because there are
plenty of php hobbyists who refuse to use frameworks because they
don't understand how they work (so they must be bad). It's basically
the reverse scenario - except that as far as I can see, it is better
to have someone bumbling around within a fixed set of functionality
than to be let loose to create havok in ways they don't understand.
return 'bye';
David Mark
> > > On Jul 28, 11:41�am, Hamish Campbell <HN.Campb...@gmail.com> wrote:
> > > > ... could program JS with an Oscilloscope and a
> > > > soldering iron if they really tried.
>
> > > ...and what's wrong with that ?
>
> > Personally I use a bar magnet and a magnifying glass. Saves amazing
> > amounts of CPU.
>
> Hehe. Yeah, my point was that there are serious experts in this forum,
> but few programmers - even good ones - have the time/inclination/
> ability to delve into the inner workings of JS (and even fewer get to
> the point where they seem to be able to quote the spec at will!).
>
> And hey, an accessible library like jQuery is [hopefully] a good entry
> point for someone who will later learn *ahem* real JS.
That's what you fail to understand. It isn't. There is no argument
for it. Search the group. Thanks.
RobG
> Aaron Gray meinte:
>
> > There's another library I have came accross that seems to do the same as
> > jQuery but seems alot lighterweight and have not heard it mentioned on clj.
>
> > http://www.domassistant.com/
>
> > Have not used it, but it has four figure version numbers and is up to
> > 2.7.1.1 so it _may_ be a good library.
>
> Dunno...
>
> line 6:
> var isIE = /*@cc_on!@*/false;
I guess it does that because shortly afterward it does:
var pushAll = function (set1, set2) {
for (var j=0, jL=set2.length; j<jL; j++) {
set1.push(set2[j]);
}
return set1;
};
if (isIE) {
pushAll = function (set1, set2) {
if (set2.slice) {
return set1.concat(set2);
}
for (var i=0, iL=set2.length; i<iL; i++) {
set1[set1.length] = set2[i];
}
return set1;
};
}
[...]
>
> And why would one want to do something like that:
Because the author(s) do no know how to implement effective feature
detection?
How about:
var HTMLArray = function () {
// Constructor
};
...
if (isIE) {
HTMLArray = Array;
}
HTMLArray.prototype = [];
HTMLArray.prototype.each = function (functionCall) {
Which extends Array.prototype in IE with an each method, but in other
browsers extends a generic array object.
--
Rob
Richard Cornford
> On Jul 28, 5:39 pm, jdalton <John.David.Dal...@gmail.com> wrote:
>> @Pink
>>
>> You might try one of the jQuery mailing
>> >>lists:http://docs.jquery.com/Discussion
>>
>> If you are on twitter.com you can message @jquery for help :)
>
>> Also for fun you can read up on the various
>> personalities here:
>>http://redwing.hutman.net/~mreed/warriorshtm/tirelessrebutter.htm
>>
> I hope this helps :D
>>
>> - JDD
> Hey Pink,
>
> The jQuery google group is excellent:
> http://groups.google.com/group/jquery-en
The JQuery group responded to the OP's question by pointing out that the
information provided was insufficient for an answer to be given
(particularly asking to see the code). Pretty much the same reaction to
the question as received here (and unsurprising as there is a minimum of
information required in any meaningful analysis).
In the end it turned out that my suspicion that the information provided
was inaccurate at least in part, due to the contradiction between the
description of the code and the symptoms, was well founded. The issue
was caused by arbitrary character sequences being written into the
javascript source code for a string literal without appropriate
escaping. A common novice mistake that easily goes unnoticed up until
the point where someone/something introduces a character that is
forbidden or problematic in a string literal, like apostrophes
(problematic) or line terminators (forbidden).
That meant that the "run it locally under Firefox, everything works
fine" was pure misdirection, as given the same data it would have failed
as reliably locally as it failed "on the host site".
> Plenty of people there (including myself) willing to
> help out.
Willingness does not necessitate ability. What I don't see on the JQuery
group is any depth of expiation, or any push to enable other posters to
become better javascript programmers. It appears that everything is
geared towards getting things 'working' in some sense, with no
consideration of how stupidly coded that 'working' outcome may be. Is
that a limitation in the ability of the participants, or a desire to
keep JQuery users as 'in the dark' as possible about javascript?
There are plenty of people here who are willing to help, but the help
offered anywhere may often not be something that the person asking for
help would be happy to hear.
> Try to post a link to a sample site if
> possible.
You see, even you think the OP has to expose the code before an answer
can be proffered.
> Unfortunately this group can be a little.. old school.
"Old school"? What can you mean by that? Are you suggesting that there
are practices and ideas in javascript programming/browser scripting that
have been superseded by more recent developments and we ("the group")
are steadfastly using and promoting them despite the tide of progress?
So are we talking about ideas such as those relating to handling browser
differences. Where the oldest idea was User Agent string based browser
sniffing (which pre-dates javascript), followed by the more potentially
more effective strategy of object inference browser sniffing (which was
very rarely implemented to get anywhere near reaching its potential),
and eventually the more rationally justified feature detection strategy.
And all of this in the dying years of the last century.
All of the proposed alternatives are old, but if any is to be regarded
as "old school" it should have to be one of the first two. But here it
is feature detection (the most modern of those strategies) that is
promoted, and UA string sniffing is ridiculed for its lack of any
technical foundation and demonstrable inability to make the required
discriminations. While in contrast it is in libraries like JQuery that
you find heavy reliance on UA string based browser sniffing and the
people promoting the strategy are the authors of those libraries.
Language use has changed over time, in terms of style. Go back to 2001
and pretty much all large-ish scale javascript design was relentlessly
OO style aping Java. While the passage of time has seen things develop
towards exploiting the functional programming aspects of javascript.
Consider the understanding of closures as an aspect of that trend. At
the turn of the century very few javascript programmers had any idea
what a closure was (at least partly as a consequence of their having
zero coverage in books of the day) and little use for them. These days
anyone who intends putting themselves forward as an expert on javascript
is going to be expected to have a good handle on closures, and the run
of the mill programmers are expected to have a working familiarity. That
trend started right here on this group. You would be hard pressed to
find a single regular participant in this group (with the obvious
exception of VK) in the middle of 2004 who was not fully familiar with
the theory, mechanism and practical applications of closures.
Similarly the "Module Pattern" (and generally the use of inline calls to
function expressions to provided a pseudo-private scope) that came as
such a new idea to so many in mid 2007 when the famous YUI blog was
first published is old enough to be regarded as "old school". It was
first published, on this group, in April-May 2003 (various examples from
function expression calls motivated by private scooping to recognisable
"module pattern" implementations). And it was participants in this group
who first took up the idea, developed and discussed it, teased out its
permutations and identified its appropriate uses, with sufficient rigor
and enthusiasm that the whole subject was played out here by the end of
2004.
So it is "old school" to be in at the point other people's new ideas of
the last couple of years really were genuinely new ides? To be, what
appears to be, 3 or 4 years ahead of the game?
And given 3 or 4 years head start to spend debating the issues do you
really think that the reasoning behind the "hatred" of these libraries
is not well thought out? After all, the idea of large-scale
general-purpose javascript/DOM libraries is hardly anything like a new
ides. When I started writing javascript back in 2001 libraries such as
'overlib' and (I think it was called something like) 'x-lib' had the
mass popularity. Maybe not to the level of current libraries, but that
is partly because the demand for javascript on the web was nothing like
what it is today (and I don't think anyone even considered marketing
them, and certainly not having t-shirts printed). Consider how critical
and argumentative this group is; is it credible that poor reasoning
about such an old idea would not have been torn apart by now in such an
environment?
> I'm pretty sure that PointedEars et. al. could
> program JS with an Oscilloscope and a soldering iron
> if they really tried. Unfortunately that sword has cut
> both ways and they're all but blind to the benefits
> that jQuery (and the other hated libraries) bring
> to real world developers.
Is that true? Do you imagine that nobody has ever attempted to enumerate
the supposed benefits of those "hated" libraries here? Granted, mostly
when you ask a 'supporter' of these libraries to enumerate the benefits
they offer, no list is forthcoming. Which always suggests to me that the
"benefits ... to real world developers" arguments are the
comprehensionless parroting of someone else's propaganda. And when the
response is 'they are too obvious to mention' I know full well that I am
not listening to reasoned argument (whenever something is really that
obvious it is also easy to justify/explain/enumerate).
When it comes down to it, the things that really are of benefit in these
things are not exclusive to these things, or maximised by these things.
A good few years of discussing these subjects suggests that all of the
benefits are achievable in other code authoring strategies, and that
some of those alternative strategies can significantly mitigate the
drawbacks of the "hated" libraries.
It may be the case that the debate of alternatives has not yet
crystallised into any formal strategies, and so code written by
participants in the debate still varies considerably in style and
structure, but still the direction chosen is away form the "hated"
libraries.
And of course some of the things put forward as benefits of these
libraries actually turn out to be drawbacks when critically examined.
It may be inevitable that most people will not appreciate being told
that they have taken a totally wrong direction, but that is not a good
reason for not telling them. And mostly when it comes to taking advice
about which path to take it is a good idea to get the advice from
someone familiar with the whole journey.
Richard.
Thomas 'PointedEars' Lahn
There is something wrong with your NetNews user agent. The last `1' in
`11:41' is _not_ followed by an unknown character.
>>>> ... could program JS with an Oscilloscope and a
>>>> soldering iron if they really tried.
>>> ...and what's wrong with that ?
>> Personally I use a bar magnet and a magnifying glass. Saves amazing
>> amounts of CPU.
>
> Hehe. Yeah, my point was that there are serious experts in this forum,
> but few programmers - even good ones - have the time/inclination/
> ability to delve into the inner workings of JS (and even fewer get to
> the point where they seem to be able to quote the spec at will!).
Those who do not even attempt to evaluate code they are using before they
are using it, who use code they do not understand in the first place, do not
deserve to be called programmers. They are only script-kiddies.
> And hey, an accessible library like jQuery is [hopefully] a good entry
> point for someone who will later learn *ahem* real JS.
1. jQuery is the exact opposite of accessible.
2. How could code lead to a greater understanding about a programming
language when one does not even bother about the possibility that it
could be bad?
> Meanwhile, I'm fixing basic PHP/SQL injection issues because there are
> plenty of php hobbyists who refuse to use frameworks because they
> don't understand how they work (so they must be bad). It's basically
> the reverse scenario - except that as far as I can see, it is better
> to have someone bumbling around within a fixed set of functionality
> than to be let loose to create havok in ways they don't understand.
You miss the point. The problem with jQuery is certainly not that the
people criticizing it here do not understand how it works. Instead they
understand how it works (or rather does not work) all too well, obviously
better than its author, as in contrast they are not only not lacking the
minimum clue but also have much a larger record of (professional) experience
than its author. As it is often the case with so-called frameworks or
(all-in-one) libraries, heavily marketed as the Second Coming of programming
and therefore easily fallen for by those new to the programming language
(who are by definition in no position to assess their quality properly).
> return 'bye';
SyntaxError: return not in function.
Please do not remove the attribution line for the precursor; especially,
you should retain all attribution lines for quotations you include.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Hamish Campbell
$ and none of my users has ever complained (or, for that matter,
noticed).
I *can* write any of the jQuery functionality by hand if I need to -
but why would I?
Andrew Poulos
Generally, to ignore what Richard, Thomas et al say on javascript
matters is a bit like driving without wearing a seat belt.
Andrew Poulos
Jorge
But you can't argue that "jQuery saves me hours and my clients $$$".
(And increased margins and productivity too).
Nor that "none of my users has ever complained (or, for that matter,
noticed)", as that's something that only he knows.
As to "Why would I (write my own library) ?", many people wouldn't
even think about it. Libraries as tools, are ok as long as they get
their jobs done. At least for the people whose interest is not in
building tools, or in JavaScriptology. And that's allright (for them).
--Jorge.
Erwin Moller
>>> On Jul 28, 11:41�am, Hamish Campbell <HN.Campb...@gmail.com> wrote:
>>>> ... could program JS with an Oscilloscope and a
>>>> soldering iron if they really tried.
>>> ...and what's wrong with that ?
>> Personally I use a bar magnet and a magnifying glass. Saves amazing
>> amounts of CPU.
>
> Hehe. Yeah, my point was that there are serious experts in this forum,
> but few programmers - even good ones - have the time/inclination/
> ability to delve into the inner workings of JS (and even fewer get to
> the point where they seem to be able to quote the spec at will!).
>
> And hey, an accessible library like jQuery is [hopefully] a good entry
> point for someone who will later learn *ahem* real JS.
Hamish,
It works the other way around.
If you want to learn something, you must start learning that something.
Make mistakes, and learn. Get good documentation and read it.
I don't think people will learn JavaScript very well by using JQuery.
They will learn how to use JQuery instead.
JQuery != Javascript.
>
> Meanwhile, I'm fixing basic PHP/SQL injection issues because there are
> plenty of php hobbyists who refuse to use frameworks because they
> don't understand how they work (so they must be bad). It's basically
> the reverse scenario - except that as far as I can see, it is better
> to have someone bumbling around within a fixed set of functionality
> than to be let loose to create havok in ways they don't understand.
I totally disagree.
Using a framework is a bad start to learn a new language.
You want to learn PHP? Learn PHP, get SQL-injected all the way if you
don't do it right from the start. That is not a bad thing, but a good thing.
That is the way real programmers are made, by making mistakes and learn
from it. NOT by babysitting and nursing them up in a framework, but by
understanding the language, the securityissue at hand, etc.
The REAL stuff.
Your way of 'learning' leads to wannabees that know how to use a certain
framework.
Their sense of security is lowered by using a framework, since they
never learn about the underlying problems.
AFTER you know how to program and use a certain language, you can MAYBE
have a look at a framework that helps you avoid braindead work.
Most will roll-their-own frameworks by then, or at least pick a
framework they understand.
>
> return 'bye';
echo 'Regards,\nErwin Moller';
Jorge
<Since_humans_read_this_I_am_spammed_too_m...@spamyourself.com> wrote:
>
> If you want to learn something, you must start learning that something.
> Make mistakes, and learn. Get good documentation and read it.
> I don't think people will learn JavaScript very well by using JQuery.
> They will learn how to use JQuery instead.
> JQuery != Javascript.
>
There are many reasons for choosing to use a library:
You may not care less about JavaScriptology, about JavaScript itself,
about object models, about inheritance, about closures, about the
DOM,
about etc.
You may just want (or need) to build a web page asap.
You may even care less about the web page itself than about its
contents.
You may not want to deal with cross-browser compatibility issues (I'm
one of those).
You may want to have to learn just one api (any api) that works (and
don't care about how it works internally).
Have you ever used a C library ?
Did you ever write your own printf() ?
--Jorge.
Erwin Moller
Hey Jorge,
Essentially what you are saying is: "If you don't care about
understanding the language you use, or you are in a hurry, use a
framework.".
To THAT I can agree.
But my message to Hamish was a reaction to:
> And hey, an accessible library like jQuery is [hopefully] a good entry
> point for someone who will later learn *ahem* real JS.
I don't think using a framework will teach the language fast.
Many (important) problems are abstracted away.
It may work, the app may work, the work gets done in time maybe, but it
is not excactly the fastest route to become better in the underlying
language.
When I must send an email in some obscure ASP/VB script from some
ancient W2000 box, I use the first working script I can find on the net
without understanding a jota of the underlying logic.
But then again, I don't want to be good with that technology, I want to
get my work done and get a cool beer. The faster, the better. ;-)
So yes, I surely can understand that attitude, but bottomline is it
won't make you GOOD with the language.
That was my only point. ;-)
>
> Have you ever used a C library ?
> Did you ever write your own printf() ?
Hell no!
Isn't that inside STNDOUT package or something?
Long time no C, for me. ;-)
And no, I don't do any machinecode either these days (6502 was my last).
Of course I rely on libs.
But I must say there is a big difference between printf() in C, and
using JQuery.
I think I can use printf() quite safely since it is used everywhere by
good programmers. JQuery has a bad reputation.
That is simply not the same.
>
> --Jorge.
Regards,
Erwin Moller
Aaron Gray
news:ee1d1aa7-c47b-4682...@1g2000pre.googlegroups.com...
Yeah, there are bits of cruft in the code.
Aaron