Dynamic loading of javascript files into web pages

[Jorge]

Only if you accept that the whole DOM and all 'namespacing' schemes have
results that are 'global'.


No. This - f - must be declared/assigned, and it must be a function if
it is to be called, but there is no reason that it could not have been
declared in the JS files that is being dynamically loaded. There is no
need for and previous or separate SCRIPT element.

Yes it could be there but of course that has several drawbacks and it
would of course not be so convenient and flexible as the degrading
script's pattern where nothing is hardcoded in the script but the
location of the source to execute: its own .innerHTML.

Anything that can be found in public archives is not secret.

Also a secret that somebody reveals somewhere e.g. in a public archive
is still a secret, although a disclosed one.

One thing
that would be seen by searching the archives is for how long this
subject has been being kicked around on this group. It is a sufficiently
old subject that some of us will remember the technique for dynamic
script insertion that worked with Netscape 4 (something that nobody
cares about at all these days).

I have no doubt about this. But if I say a=b don't just tell me no+ go
search why, just tell me why not.

And you are stressing "parallel" when if the HTTP constraint on only
having two simultaneous connections to the server is in force the number
of resources that can be downloaded at the same time is limited to two.

No current browser has this limit set to 2, no matter what any
standard says. And no server either (neither ?).

The result is not parallels, it is just less serial than making the next
request after the resource for the last had been delivered (and possibly
not even then, depending on the demand for connections to download other
resources).

Haven't you seen the results of the tests in the links that I've
posted ?

<snip>> How's posting code that proves what I say is pretending ?

<snip>

How about posting explanations that state what it is you think the code
you are posting shows ?

Yeah, great. Thanks.

 

[Jorge]

Bad assumption, but irrelevant here.

Bad assumption ? At the top level ? in a browser ? How so ?

- [[scope]] === global context, and

Not exactly.

What else is in the scope chain at the top level ?

And are you planning to run this XHR/eval combo in the global
context? I would expect it to reside in a function.

Yes it will very likely most often be isolated into a (function()
{'code'})(); context capsule;

See above.

You too.

 

[Jorge]

Using - document.write - really should not do that, and I would be
massively suspicious of any evidence that it does.

Times are changin', see it by yourself:

http://jorgechamorro.com/cljs/071/

In at least Safari 4, FF3.5b and Opera 10b.

 

[Jorge]

Suit yourself, but it appears that some people are getting annoyed by
your additions.

They certainly shouldn't, it's so irrational, but as they've got that
superiority complex about anything-Crockford...
I mean, the usual bunch of conceited, bigoted regulars, it's pitiful.

 

[Richard Cornford]

Times are changin', see it by yourself:

http://jorgechamorro.com/cljs/071/

In at least Safari 4, FF3.5b and Opera 10b.

See what for myself? In what way does this demonstrate the use of -
document.wirte - to create script elements with SRC references to
external resources failing to halt the HTML parser?

Richard.

 

[Jorge]

See what for myself? In what way does this demonstrate the use of -
document.wirte - to create script elements with SRC references to
external resources failing to halt the HTML parser?

Read again:

"By making them dynamically declared script elements (either using
document.write or dynamic SCRIPT elements), it allows
**concurrent**loading** with other elements."

 

[Richard Cornford]

Read again:

Read what again?

"By making them dynamically declared script elements (either using
document.write or dynamic SCRIPT elements), it allows
**concurrent**loading** with other elements."

Where is the evidence for this?

Richard.

 

[Jorge]

Read what again?


Where is the evidence for this?

In that it takes 1/4th the time ?
In that the network throughput grows 4x ?
Are you kidding ?

 

[Richard Cornford]

In that it takes 1/4th the time ?

What is the "it" that takes 1/4 of the time? And in what way does that
provide evidence for concurrent loading?

In that the network throughput grows 4x ?
Are you kidding ?

No, I am asking questions. So far you are not answering any of them
(or even trying to).

Richard.

 

[Jorge]

(...)

Grrrr + :-(

 

[rf]

Grrrr + :-(

WTF are you growling about?

And no, I'm not going to search the thread to find out.

 

[Jorge]

WTF are you growling about ?

About (...), WTF !

 

[David Mark]

Bad assumption ? At the top level ? in a browser ? How so ?

For all intents and purposes, this thread was over days ago. Why are
you still in here going around in circles like a puppy chasing its
tail (and periodically getting smacked on the nose for the
annoyance.) You are really fouling up everything for casual readers.

<script>alert(this === window);</script>

For seemingly the 8 millionth time, in browsers, the global window
property is sometimes a reference to the Global Object, but you should
not (and don't need to) assume that.

[snip]

We're done here, Jorge. All of the answers are at the end of your
nose.

 

[David Mark]

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are mistaken, as proven recently.  Find the proof below again, ina more
elaborated form.

Now include variable declarations in `code'.  Not only that the variables
will not be available globally afterwards, as I have showed; they will also
be deletable (as per Specification), as Martin has pointed out.

[snip code]

I'm not too worried about the variables being 'delete'd - this rarely
happens and can be avoided - but I see your point about global
availability, and now I remember why I didn't use this form myself. Your
example nicely demonstrates "what's so bad about" just moving the 'eval'
to a separate function. It will only work if the evaluated script
doesn't declare new global variables, or if these variables are never
accessed outside the included script. It's possible to make it work with
this restriction, but it's very limited, and not a good general solution.

What I have been using is execScript(), if available, or else
window.eval, if available. I'm not happy with this solution, because
both are nonstandard, and not guaranteed to work (IIRC, window.eval is
even guaranteed *not* to work in ES5 strict mode). I wouldn't be
surprised if there were reasonably current UAs which support neither.

Neither of those are acceptable.

There's a lot about this topic on the web, and in the group archives.
Has there ever been a consensus in this group about the best/safest way
to evaluate code in global context?

As have been mentioned in this thread, search the archive for "dynamic
script injection" (and/or "Webb.") You don't need execScript and
shouldn't use window.eval under any circumstances.

 

[David Mark]

Yes, I just said that.

You said you were using them as well, which is not acceptable.

The problem is that there has been so much discussion about it that it
makes the relevant bits hard to find. If this has been discussed so

Not really.

much, and is frequently asked, it should probably go in the FAQ, which

Tell the FAQ maintainer.

would save people from sifting through thousands of posts containing
half-solutions and esoteric cases every time.

I told you whose posts to read. Skip to the end.

Is it really too much to ask which is the "recommended" approach? Is it

I told you.

creating a script element, setting its .type, adding the code as its
.text, and appending it to the body? Which problems can be expected with

That's one of three ways and you have to feature test to determine
which will succeed (if any.) I know I mentioned in this thread that
there is a method in My Library for this. Just type "browser
scripting library" into your favorite search engine (it's invariably
the top result.)

this approach? Is window.setTimeout(code, 0) equivalent, as long as
setTimeout is available, and order of execution doesn't matter?

Of course not. For one, the idea is to execute the script
immediately.

I don't
mind doing research, but I do mind the "I know, but I won't tell" attitude.

That attitude is in all in your head. You could search the archive,
see my example, Google for Randy's examples, etc. In browser time,
this is all ancient history. It's not up to others to give you
answers on a silver platter either (this is not a help desk.)

 

[Dr J R Stockton]

In comp.lang.javascript message <aca954a0-7e87-42d6-81fd-6ae2325bfad5@l5
g2000vbp.googlegroups.com>, Fri, 26 Jun 2009 18:49:05, One Dumm Hikk
<[email protected]> posted:

I see the reappearance of a dropout.

 

[David Mark]

In comp.lang.javascript message <aca954a0-7e87-42d6-81fd-6ae2325bfad5@l5
g2000vbp.googlegroups.com>, Fri, 26 Jun 2009 18:49:05, One Dumm Hikk
<[email protected]> posted:

I see the reappearance of a dropout.

You really take the cake, Johnny. I'll speculate wildly and say he
got tired of listening to your shit. But the main point is that you
have no idea why anyone posts here (or not.)

Please try to stay on topic. It's a good idea to read the newsgroup
and its FAQ, etc.

 

[One Dumm Hikk]

You really take the cake, Johnny.  I'll speculate wildly and say he
got tired of listening to your shit.  But the main point is that you
have no idea why anyone posts here (or not.)

Please try to stay on topic.  It's a good idea to read the newsgroup
and its FAQ, etc.

Don't waste your time on him, he isn't worth
the effort. I stopped posting here for personal
reasons (health mostly). The only reason I am
back now is because Michael emailed me (CC
actually) and pointed me to the thread.
My GG account had even lapsed.

Jorge, if you want to truly discuss the aspects
of dynamically loading scripts, email me. I
don't have an issue discussing it as long as
it stays a constructive discussion and stays
away from this "My approach is perfect" non-
sense. I can tell you the flaws in the
approach I use, and ways around them. How many
people that use/wrote jQuery and the likes
can do that?
My goal isn't to become the "leading expert"
on the topic but rather to keep learning the
topic as I use dynamic loading exclusively on
an Intranet setting.

I just hate and despise the GG interface(mostly
that annoying ass captcha pos thingie) and
not setting up a new Usenet account just for
this discussion unless people truly show that
they want to discuss it instead of all the
"I am right" crap thats going on.

Randy

 

[Jorge]

Conrad Lender wrote

(...)
Is it really too much to ask which is the "recommended" approach? Is it
creating a script element, setting its .type, adding the code as its
..text, and appending it to the body? Which problems can be expected with
this approach? Is window.setTimeout(code, 0) equivalent, as long as
setTimeout is available, and order of execution doesn't matter?

Good question.

1.- Create and insert an <script>'code'</script>

2.- Use myEval= eval; myEval('code');

3.- Use window.eval().

4.- Use setTimeout('code', 0);

5.- function gEval (code) {
with (window) {
return eval(code);
}
}

6.- ?

2 and 3 are unreliable because so many browsers still scope the eval in
the current context. 5 is an idea I've had while writing this. 4 is for
sure executed asynchronously, and (1) ought to be executed
asynchronously too. 2,3,5 execute synchronously and can return a value
to the current context. 1,4 can't. So, which is better ? Is there any 6 ?

 

[Dr J R Stockton]

In comp.lang.javascript message <48d78707-9188-4c24-8be3-01d8d6f62fc2@f1
6g2000vbf.googlegroups.com>, Mon, 29 Jun 2009 17:55:18, David Mark

You really take the cake, Johnny. I'll speculate wildly and say he
got tired of listening to your shit. But the main point is that you
have no idea why anyone posts here (or not.)

Please try to stay on topic. It's a good idea to read the newsgroup
and its FAQ, etc.

We know that he abandoned his agreed task of FAQ maintainer without the
courtesy of posting a resignation to the group. For that, death or a
reasonable approximation thereof is the only honourable excuse.

But abandoning agreed responsibilities seems to be a national custom
over there; consider for example what happened to the moderated Y2k
newsgroup.

Perhaps I should do here as I have done in other groups : kill-rule
@gmail - it does make things more pleasant, by getting rid of such a
large proportion of the puerile and comparatively few unknown others
(known others can have a preceding accept rule; unknowns usually get
seen by quotation).