From: Garrett Smith on
Jorge wrote:
> On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>> (...)
>> A Loader adds a load callback to a script element, then appends that
>> script, triggering the browser to load the script. When the script's
>> onload fires, the callback calls callback function.
>>
>
> IIRC, I've seen a couple of strange things happen when doing so. In
> some browser(s) the onload may not even fire for <script>s. And in
> some browsers I've seen both the <script>'s source being parsed/run
> synchronously and the onload event being handled synchronously too
> (when the <script> was cached and got fetched immediatly, on-the fly,
> from the cache). Is it me, is it too much coke, or has somebody else
> seen any of these too ?

OK, you've got me. All the food got me a little euphoric yesterday. I
Wrote "Solution" when I should have written: "Untested solution".

Regarding the timing problems you mention with onload, I've not seen those.

Then again, I've not testing dynamic script injection much. For
requesting remote data, I have always used XHR or iframe. Those work
fine when used sparingly with small amounts of data.

Using dynamic script injection, the loader would listen for script's
onreadystatechange and check the readyState:

function loaderWrappedCallback() {
var readyState = script.readyState;
// TODO: Timeout events.
if(!readyState || "complete" === readyState) {
callback();
}
// TODO: Error handler.
}
}

Further testing is warranted before such experimental technique can be a
recommended solution.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on
On Nov 27, 2:19 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> Jorge wrote:
> > On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >> (...)
> >> A Loader adds a load callback to a script element, then appends that
> >> script, triggering the browser to load the script. When the script's
> >> onload fires, the callback calls callback function.
>
> > IIRC, I've seen a couple of strange things happen when doing so. In
> > some browser(s) the onload may not even fire for <script>s. And in
> > some browsers I've seen both the <script>'s source being parsed/run
> > synchronously and the onload event being handled synchronously too
> > (when the <script> was cached and got fetched immediatly, on-the fly,
> > from the cache). Is it me, is it too much coke, or has somebody else
> > seen any of these too ?
>
> OK, you've got me. All the food got me a little euphoric yesterday. I
> Wrote "Solution" when I should have written: "Untested solution".
>
> Regarding the timing problems you mention with onload, I've not seen those.
>
> Then again, I've not testing dynamic script injection much. For
> requesting remote data, I have always used XHR or iframe. Those work
> fine when used sparingly with small amounts of data.
>
> Using dynamic script injection, the loader would listen for script's
> onreadystatechange and check the readyState:
>
> function loaderWrappedCallback() {
>    var readyState = script.readyState;
> // TODO: Timeout events.
>    if(!readyState || "complete" === readyState) {
>         callback();
>      }
> // TODO: Error handler.
>    }
>
> }

That's not a cross-browser solution either.

>
> Further testing is warranted before such experimental technique can be a
> recommended solution.

Solution for what? Knowing exactly when any random script has
finished loading? That's a fantasy aspiration. And I've seen people
trying to do similar things in projects where they actually have
control over the loaded scripts (or define the standards for them).

The only sane solution is to call the callback from the loaded
script. I know that doesn't fit the proposed fantasy design, but I
think it bears repeating at this point.
From: Richard Maher on
Hi David,

> Solution for what?
I am also not sure what problem the proposed solution solves. I thought the
OP wanted to delay till onload fired unless onload has fired in which case
run now.

> Knowing exactly when any random script has
> finished loading? That's a fantasy aspiration.
Based on available evidence I have to disagree. Depending of course on what
exactly you mean by "exactly" :-)

As well as the cross-browser issues I'd include that ONERROR as well or you
might find your CALLBACK being a tad unreliable, but then you didn't like
"onerror" either.

BTW. Is the thrust of the requirements spec for this question the fact that
various "libraries" have become so bloated and convoluted that they can no
longer be feasibly loaded at "onload" time? So when some one says, for
example, "jQuery's footprint is 120KB" then that's just the bootstarp code
and oodles more will be lazily-loaded?

Cheers Richard Maher


"David Mark" <dmark.cinsoft(a)gmail.com> wrote in message
news:69d8195b-0814-4342-bc4b-c6103f6c23ca(a)p35g2000yqh.googlegroups.com...
On Nov 27, 2:19 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> Jorge wrote:
> > On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
> >> (...)
> >> A Loader adds a load callback to a script element, then appends that
> >> script, triggering the browser to load the script. When the script's
> >> onload fires, the callback calls callback function.
>
> > IIRC, I've seen a couple of strange things happen when doing so. In
> > some browser(s) the onload may not even fire for <script>s. And in
> > some browsers I've seen both the <script>'s source being parsed/run
> > synchronously and the onload event being handled synchronously too
> > (when the <script> was cached and got fetched immediatly, on-the fly,
> > from the cache). Is it me, is it too much coke, or has somebody else
> > seen any of these too ?
>
> OK, you've got me. All the food got me a little euphoric yesterday. I
> Wrote "Solution" when I should have written: "Untested solution".
>
> Regarding the timing problems you mention with onload, I've not seen
those.
>
> Then again, I've not testing dynamic script injection much. For
> requesting remote data, I have always used XHR or iframe. Those work
> fine when used sparingly with small amounts of data.
>
> Using dynamic script injection, the loader would listen for script's
> onreadystatechange and check the readyState:
>
> function loaderWrappedCallback() {
> var readyState = script.readyState;
> // TODO: Timeout events.
> if(!readyState || "complete" === readyState) {
> callback();
> }
> // TODO: Error handler.
> }
>
> }

That's not a cross-browser solution either.

>
> Further testing is warranted before such experimental technique can be a
> recommended solution.

Solution for what? Knowing exactly when any random script has
finished loading? That's a fantasy aspiration. And I've seen people
trying to do similar things in projects where they actually have
control over the loaded scripts (or define the standards for them).

The only sane solution is to call the callback from the loaded
script. I know that doesn't fit the proposed fantasy design, but I
think it bears repeating at this point.


From: David Mark on
On Nov 27, 10:15 pm, "Richard Maher" <maher...(a)hotspamnotmail.com>
wrote:
> Hi David,
>
> > Solution for what?
>
> I am also not sure what problem the proposed solution solves. I thought the
> OP wanted to delay till onload fired unless onload has fired in which case
> run now.
>
> > Knowing exactly when any random script has
> > finished loading?  That's a fantasy aspiration.
>
> Based on available evidence I have to disagree. Depending of course on what
> exactly you mean by "exactly" :-)

What evidence is that?

>
> As well as the cross-browser issues I'd include that ONERROR as well or you
> might find your CALLBACK being a tad unreliable, but then you didn't like
> "onerror" either.

If a script is a 404 or has a syntax error or whatever, the document
that included it better be equipped to do without it. And it
shouldn't need any sort of callback to tell it a script failed to
load.

>
> BTW. Is the thrust of the requirements spec for this question the fact that
> various "libraries" have become so bloated and convoluted that they can no
> longer be feasibly loaded at "onload" time? So when some one says, for
> example, "jQuery's footprint is 120KB" then that's just the bootstarp code
> and oodles more will be lazily-loaded?

God only knows what jQuery developers are thinking. The base script
is too large and slow for mobile use (and full of extraneous garbage
that nobody needs). It makes life "simpler" by adding tons of
complexity and apps smaller by adding lots of unneeded script. Lazy
loading on top of it would be slower than including the scripts
normally. And they don't know how to do feature testing yet anyway,
so how would they decide what to lazy load. ;)
From: Richard Maher on

"David Mark" <dmark.cinsoft(a)gmail.com> wrote in message
news:f3503614-48a8-4873-9141-9029a10bcce9(a)m3g2000yqf.googlegroups.com...
> What evidence is that?

Anecdotal++ With all browsers tested to date (Chrome, FF, and Safari) the
onload or onerror combo fires every time. With IE 7,8 the readystate value
may be a source of contention but the event(s) fire every time. Do you have
any evidence to the contrary?

Our cases deal only with <script> injection and specifically with JSON
Callbacks. We are accessing and Application (Service-Now) in our Software
Providers "cloud" and as the network/application response to The States can
be woeful we desperately needed local (but cross-domain) data and
business-rule access/validation. We also have an SSO product that can
substitute a login page for our scripts when the session times-out.

I submit to you (sorry "The Group" :-) that we have no silent failures and
we can verify the completeness of the load of our scripts. So you maintain
that I am living in cloud cuckoo land?

Cheers Richard Maher