From: David Mark on
On Nov 24, 3:18 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Nov 24, 1:41 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > On Nov 23, 3:51 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> > > Typical of this group, which is why it's become mostly irrelevant.
> > Typical of you, you don't know your evidence.  ISTM that you have
> > floated the posting traffic in the jQuery group(s) as an indicator of
> > relative relevance.
>
> Indeed.
>
> The lower signal/noise ration in here and the fewer posts is an
> indicator as well.

Yes, it is very noisy in the jQuery group as few seem to have a clue
what they are discussing. ;) How is that a plus?

>
> > I will assume you still subscribe to that theory,
> > at least up until you read the next couple of lines (then cognitive
> > dissonance will kick in and you will find a new belief).
> > Know what this is?
> > 4206     4167    3792    3351    2655    2904    2895    2651    2500
> >          2251    1866
> > The tallies for the last eleven months for the primary jQuery user
> > group.  Last month here was 2169.
>
> The jQuery group is being moved away from Groups because of
> unmanageable spam. The number of readers may be reflected by this.

Yes, some of them may be spammers that got through rather than
readers. So you adjust the totals downward to compensate.

>
> Or perhaps jQuery is becoming so well known and documented that not as
> many people need help with it. How do you like them apples? :)

You know that's not true (at least if you have ever read the code).
Virtually every jQuery example in print or online uses the attr
method. How do you like that apple?

http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/e106af2d970d9b29#

It's rotten.

>
> Or perhaps jQuery popularity is fading. If that's the case, so be it.

Yes, IE8's arrival coincides almost exactly with the nosedive trend.
Who could have seen that coming? :)

> Perhaps it will be replaced by something different as the most popular
> scripting library. Doesn't matter to me.

Obviously it will be "replaced". Science doesn't have any pity on
lazy, destructive code monkeys. And neither does business, but it
takes a while for ideas to percolate to that level.
From: David Mark on
On Nov 24, 3:15 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> On Nov 24, 12:02 am, David Mark <dmark.cins...(a)gmail.com> wrote:
>
> > On Nov 23, 11:12 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote:
> > > 1) That depends on the first script setting an onload listener. What
> > > if it is loaded after window.onload?
> > And, pray tell, what would have loaded it after onload?
>
> For example, something like GreaseMonkey. Or any tool which injects
> scripts. Or perhaps a bookmarklet. Use your imagination, there are a
> number of cases where a script under your control is injected into a
> document and you have no control over the source document or when/how
> your code gets inserted.

And, as mentioned, there is no magic property to determine if the
document has loaded. End of story for those examples.

>
> The ajax/eval method was just an example.

Yeah, that's the one you came up with, so that's the one I responded
to.
From: wilq on
On Nov 24, 3:48 pm, "Evertjan." <exjxw.hannivo...(a)interxnl.net> wrote:
> wilq wrote on 24 nov 2009 in comp.lang.javascript:
>
> > From what I know there is no simple way to check that.
>
> check what?
>
> [please always quote on usenet]
>
> > Re: Can script determine if window.onload has already fired?
>
> Sure, just start the onload function with
>
> var onloading = true;
>
> ans check that in your script.
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

I think that this problem might be more complicated than you think ;)
Please consider all cases - together with lazy load :)
From: David Mark on
On Nov 25, 3:42 am, wilq <wil...(a)gmail.com> wrote:
> On Nov 24, 3:48 pm, "Evertjan." <exjxw.hannivo...(a)interxnl.net> wrote:
>
>
>
> > wilq wrote on 24 nov 2009 in comp.lang.javascript:
>
> > > From what I know there is no simple way to check that.
>
> > check what?
>
> > [please always quote on usenet]
>
> > > Re: Can script determine if window.onload has already fired?
>
> > Sure, just start the onload function with
>
> > var onloading = true;
>
> > ans check that in your script.
>
> > --
> > Evertjan.
> > The Netherlands.
> > (Please change the x'es to dots in my emailaddress)
>
> I think that this problem might be more complicated than you think ;)
> Please consider all cases - together with lazy load :)

Realize that lazy loading of scripts is often indicative of lazy
programmers trying to hide that they are using much too general (and
therefore bloated) scripts. Or it may be Ajax-itis (the compelling
need to cram every app into one document).
From: beegee on
On Nov 25, 4:04 am, David Mark <dmark.cins...(a)gmail.com> wrote:

> Realize that lazy loading of scripts is often indicative of lazy
> programmers trying to hide that they are using much too general (and
> therefore bloated) scripts. Or it may be Ajax-itis (the compelling
> need to cram every app into one document).

I think this was a *lazy* reply. There is a compelling case to be
made to a web user experience that resembles a stand-alone
application. Users generally get nervous when they are directed off
the home page. Even web 2.0 experiences like Facebook (basically 2
pages) are confusing to many. Now, Ajax in it's current state may not
be the way to get to the one-page application but the trend is to get
there.

The YUI Loader component is an attempt (unsuccessful in my opinion) to
implement the component approach of application development. In the
end, the suggestion of testing a global variable is exactly what the
OP is going to have to do. Every single script he downloads is going
to have to know of this variable or function. That IS the current
state of browser script load notification. I don't believe saying
that the need for such an approach shows bad design is correct.

Bob