Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Dynamic loading of javascript files into web pages

Reply
Thread Tools

Dynamic loading of javascript files into web pages

 
 
David Mark
Guest
Posts: n/a
 
      06-28-2009
On Jun 28, 3:52*am, Jorge <(E-Mail Removed)> wrote:
> On Jun 28, 9:23*am, kangax <(E-Mail Removed)> wrote:
>
>
>
> > Garrett Smith wrote:
> > > Jorge wrote:
> > >> On Jun 27, 7:23 pm, Garrett Smith <(E-Mail Removed)> wrote:
> > >>> (...)
> > >>> Steve says the technique is "safer". It is less safe because of theuse
> > >>> of eval. That point should have been clear.(...)

>
> > >> BTW, could you explain to me why/how is it any unsafer eval
> > >> (script.text) than a <script> tag ?

>
> > > The eval function uses the calling context's [[Scope]], Variable object,
> > > and |this| value.

>
> > > When eval is called, and the code inside eval is parsed, assignment to
> > > identifiers inside that eval'd code resolve to the calling context's
> > > variable object when it is invoked.

>
> > I know that ES3 allows for implementations to throw EvalError with
> > indirect eval calls, but don't browsers instead evaluate in a global scope?

>
> > (this happens in at least FF 3 and Safari 4)

>
> > var x = 'outer';
> > (function(){
> > * *var x = 'inner';
> > * *return this.eval('x');

>
> > })();

>
> var x = 'outer';
> (function f () {
> * *var x = 'inner';
> * *alert(window.eval('x'));


There's no guarantee that this method will exist on the window object,
which is not necessarily the Global Object anyway.

>
> })();
>
> --> outer
>
> var x = 'outer';
> (function f () {
> * *var x = 'inner';
> * *alert(eval('x'));
>
> })();
>
> --> inner


Proves absolutely nothing.
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      06-28-2009
On Jun 28, 5:45*pm, Conrad Lender <(E-Mail Removed)> wrote:
> On 27/06/09 10:01, Garrett Smith wrote:
>
> > <FAQENTRY>
> > Q: I saw a video online. Why wasn't it in the FAQ?
> > A: Video presentations often contain advice that is either
> > incorrect or inadvisable. It possible, though unlikely, that the video
> > has not been reviewed and contains accurate and valuable information.
> > Before posting a request for review, please search the archives for
> > discussion about the video.
> > </FAQENTRY>

>
> I don't think that's necessary. The only person who frequently asked
> this question is Jorge, and he won't need an FAQ entry about it. He's
> promoting some links/videos which he considers valuable, and I don't
> think he'll stop until he receives a plausible explanation.
>
> Jorge, I see what you're doing, and I understand the motivation, but
> adding the same list of links after every repost of FAQ 3.2 isn't going
> help much. I suggest you make a separate post about these links, and ask
> why they shouldn't be included in the FAQ. Maybe we'll get some kind of
> review out of that thread. Personally, I've become a bit disillusioned
> by Douglas Crockford's idea of the "Good Parts" of JavaScript. This is
> mostly due to what I've seen on the JSLint mailing list.
>
>
>
> > Steve:

> ...
> > | I get all the script elements, I loop through them, until I find the
> > | script whose name is "menu jay", "menu-degrading.js" and then I look
> > | at its innerHMTL property.

>
> Thanks for transcribing the video, but usually bloopers are ommitted
> from a transcription. Reproducing them verbatim ("menu jay") doesn't
> really serve any purpose, unless you want to discredit the speaker.
> Giving a presentation without making mistakes is a LOT harder that
> writing a piece of text.
>
> > None of the three reasons is true. All are blatantly false and in being
> > false, they serve as reasons for eschewing this technique.

>
> JFTR, I don't recommend this technique either. The fact that it's
> invalid HTML is reason enough for me. AFAIK, neither Souders nor Resig
> actually use it anywhere. As far as I'm concerned, it's just an
> experiment, and shouldn't be given so much attention, and Souders
> shouldn't present it as a viable way to improve preformance. He has
> other, much better solutions for loading scripts asynchronously.
>
> > AISB, eval is called in global context. Steve did not mention this, and
> > the code is so naive that I doubt he is even aware of it, but the code
> > must exist in global context, or use a separate sandbox function.

>
> What's so bad about a calling a separate function to do the eval()? This
> will make sure that the JS string is always evaluated in global context,
> and it also keeps the 'eval' out of the loader code, which makes
> minification easier:
>
> function evil (code) {
> * * return eval(code);
>
> }
>
> // later...
> xhr.onreadystatechange = function () {
> * * if (xhr.readyState == 4) {
> * * * * // ....
> * * * * evil(xhr.responseText);
>
> > Another problem with eval is that when an EvalError occurs, the browser
> > may not provide information about what was being eval'd that caused the
> > problem. Instead, the browser will state that eval(s) caused a problem.
> > Since eval can't be stepped into, it is harder to debug.

>
> This is why we use settings/flags for these optimizations: turn them off
> during development and bugfixing, turn them on in production (assuming
> that the optimization won't create any bugs by itself). Some library
> (Dojo?) automatically adds a comment line at the end of script files to
> help in debugging, and I recently read a blog post where somebody
> suggested that these hints should be standardised (for debuggers like
> FireBug). Can't find the link right now, might have been on Ajaxian.
>
> Similar hints could be added to the example above:
>
> function evil (code, url) {
> * * if (url) {
> * * * * code += "\n// source: " + url;
> * * }
> * * return eval(code);
>
> }
>
> // later...
> xhr.onreadystatechange = function () {
> * * if (xhr.readyState == 4) {
> * * * * // assuming scriptURL was set earlier:
> * * * * evil(xhr.responseText, scriptURL);
>
> > It is less clear, more complicated because it
> > requires more code inside menuteir.js to execute the inline script
> > content. The menuteir.js should not be have knowledge of the performance
> > tricks used to include it. It severely complicates things; it does not
> > make things simpler, nor clearer.

>
> It may be more complex, and less clear, but performance tweaks often
> are. There's always a tradeoff. I don't think his example code is usable
> as-is, but his overview of techniques and the analysis of current
> browser behaviors is interesting. Two slides at the end of the
> presentation ("impact on revenue" and "cost savings") indicate that for
> some companies, at least, the added complexity may well be worth it.
>
> > The "Managed XHR" solution also requires eval, and has all the
> > complications associated with that, just as in Dojo.

>
> But at least it's valid, and it should be well enough supported, as long
> as XHR is available. I'm actually using this technique in a small
> project since April (about 80 users, not in a LAN environment), just to
> see if there are any practical problems with this approach. If there
> were, the XHR injection could be turned off by flipping a config
> setting, but so far it hasn't been necessary.
>
> > Technique 4 Script onload aka "The Best One", shows code that modifies
> > Host objects with expandos. For reasons that have been discussed here
> > many times, code which modifies host objects is error prone.

>
> I thought he said there was no single "best" solution. Anyway, the
> expandos shouldn't hurt if you choose their names carefully, and you
> could easily implement the same thing without expandos if you think they
> are that dangerous.
>
> > I do agree that this deserves mention in the FAQ. If Steve's book is
> > going to be included, it ought to mention that his application design
> > advice is considerably harmful.

>
> If the FAQ had a more comprehensive book list, okay. But as long as that
> isn't the case, why single out this book as "bad advice", and ignore all
> the other books which couldn't be included in the FAQ because they
> contain errors?
>


No way his book is going in the FAQ, unless it is specifically
recommended against.

This is another one of these guys who think programming is making
videos of themselves, using the word "awesome" a lot, congratulating
fellow ignoramuses on their videos, etc. He very obviously knows
nothing about browser scripting or sound Web development techniques
(echoing the familiar Web2.0 follies of the last four years or so.)
These hucksters are part of the past; never mind if their programs are
still in syndication (so is Gilligan's Island.)
 
Reply With Quote
 
 
 
 
One Dumm Hikk
Guest
Posts: n/a
 
      06-29-2009
On Jun 27, 9:39 am, Jorge <(E-Mail Removed)> wrote:
> On Jun 27, 10:42 am, Gregor Kofler <(E-Mail Removed)> wrote:
>
> > (...)
> > As Jorge already mentioned:http://www.youtube.com/watch?v=52gL93S3usUandthe "degrading script
> > pattern" - it escapes me where the actual problem is, requesting such a
> > bizarre "solution".

>
> The problem is:
>
> - Given a script that has not been loaded yet (still loading), -
> usually a dynamically inserted one-,
> - Find the best way to have some piece of code run asap, immediatly
> after the script (above) has loaded and executed.
>
> (note that "onload" is not -usually- available on <script> tags in
> most browsers)


That is trivial to do. Again, people try to make this stuff
harder than it has to be. Want a fool proof way to make a script
in an external file execute and know that is has loaded? Search
the archives, I have shown this MANY times and it was even before
many people knew JRs name.
At the end of the external file, place the call to the function
that you want executed. It will NOT get executed until the file
is loaded and it will get called only when the file gets loaded.
Stop making this harder than it has to be. Sheesh people.

On Jun 27, 10:30*am, Jorge <(E-Mail Removed)> wrote:
> On Jun 27, 3:49 am, One Dumm Hikk <(E-Mail Removed)> wrote:
> > Dynamically loading script files to speed up the loading process?
> > Garbage.

>
> > What it will do, if done properly, is speed up the initial
> > rendering of the page. But it WON'T speed up load time of the
> > files and will actually slow it down. The reason it will
> > actually slow it down is because it has to do more work to
> > load the files. Whether the file is static coded or dynamically
> > loaded, the file still has to be downloaded from the server.
> > Want it to download faster? Make the file physically smaller.
> > Any other advice is magical hocus-pocus for making it load
> > faster if everything else is the same.
> > (...)

>
> I'm not sure why do you say so, as it's obvious (isn't it ?) that
> latency times add up when the scripts are loaded in series.


I say that because its patently true. Unless you want to try to
convince me that connection speed is determined by how the file
was attempted to be loaded. Again, take a HARD look at the original
script, how it was written, and how it would work. Then let's
discuss what it will or won't do.

> And for servers that throttle downloads (more and more each day, e.g.
> youtube, me.com...), the time to download n scripts in parallel is not
> necessarily === n* the time to download a single one.


How a file is called is irrelevant to the amount of time it takes to
download that file. IE is notorious for loading multiple files at once
irregardless of how you try to load it.

For a file that is of size S, it will take a given amount of time T,
to
download the file from the server *irregardless of how its requested*
if
all other parameters are equal. Same network speed, same processes on
the
computer making the request, same server load.

The difference it makes is the appearance of loading faster by
rendering
the HTML aspects of the page first.

Has John Resig gotten any clue about JS in the last 18 months or so?
If he hasn't, then he still doesn't have a clue.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      06-29-2009
On Jun 28, 3:05*pm, "Richard Cornford" <(E-Mail Removed)>
wrote:
> Jorge wrote:
> > Come and see it by yourself:

>
> > Parallel script loading SEVERELY cuts scripts loading time:

>
> >http://jorgechamorro.com/cljs/068/

>
> Once again, you show the experiment but not the reasoning that gets you
> from the results of that experiment to your (very general) conclusion.
>
> There is also some significant information missing, such as how many
> simultaneous HTTP connections the server delivering the JS files is
> configured to allow. Because while the HTTP spec states that only 2
> simultaneous connections should be made to a server (RFC 2616, Section
> 8.1.4, Paragraph 6) some user agents have been observed to make
> considerably more (10 to 20 in extreams).


In this regard the limiting factor seems to be in the browsers
themselves not in me.com.

> The problem with deducing your general conclusion that "Parallel script
> loading SEVERELY cuts scripts loading time" from your experiment is that
> your experiment takes place after the page has loaded; at a time when
> parsing and (progressive) rendering are not active and when there is no
> ongoing demand to be downloading resources (when no HTTP connections are
> being called upon to do other things).


Yes, and ... ? Of course when/if there aren't for any reason any more
available download "slots" downloading can't/won't take place in
parallel.

> All that actually is shown by the experiment is that if you only use one
> HTTP connection (download resources serially) the process takes longer
> than if you use more than one connection at the same time. Hardly
> surprising as if the number of connections made did not influence
> download performance then there would be no reason for ever making more
> than one connection to a server at a time.


Yes and no. The point is that a series of <script> tags hardcoded in
the source .html will be loaded in series while the same <scripts>
inserted dynamically load in parallel.

And then the problem of synchronizing load times and execution times
arises, hence Resig's degrading script tag idea becomes relevant as a
solution to a problem previously inexistent.

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

It times the loading of 4 scripts:

(1)- dynamically inserting them all at once
(2)- dynamically inserting them in series
(3)- document.writting them all at once
(4)- normally: 4 <script> tags hardcoded in the .html source.

(1) is the fastest in all the current and past browsers. Only the
latest Safari 4, FF3.5 beta and Opera 10 beta manage to speedup (3)
and sometimes (4) as well.

All the action now takes place before onload.

--
Jorge.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      06-29-2009
One Dumm Hikk wrote:
> On Jun 27, 9:39 am, Jorge <(E-Mail Removed)> wrote:
>> On Jun 27, 10:42 am, Gregor Kofler <(E-Mail Removed)> wrote:
>>
>>> (...)
>>> As Jorge already mentioned:http://www.youtube.com/watch?v=52gL93S3usUandthe "degrading script
>>> pattern" - it escapes me where the actual problem is, requesting such a
>>> bizarre "solution".

>> The problem is:
>>
>> - Given a script that has not been loaded yet (still loading), -
>> usually a dynamically inserted one-,
>> - Find the best way to have some piece of code run asap, immediatly
>> after the script (above) has loaded and executed.
>>
>> (note that "onload" is not -usually- available on <script> tags in
>> most browsers)

>
> That is trivial to do. Again, people try to make this stuff
> harder than it has to be. Want a fool proof way to make a script
> in an external file execute and know that is has loaded? Search
> the archives, I have shown this MANY times and it was even before
> many people knew JRs name.
> At the end of the external file, place the call to the function
> that you want executed.


Yes we do that in e.g. every JSONP response.

> It will NOT get executed until the file
> is loaded and it will get called only when the file gets loaded.
> Stop making this harder than it has to be. Sheesh people.


That f() must be a global and requires a previous, separate <script>.
Resig's solution requires none of these.

> On Jun 27, 10:30 am, Jorge <(E-Mail Removed)> wrote:
>> On Jun 27, 3:49 am, One Dumm Hikk <(E-Mail Removed)> wrote:
>>> Dynamically loading script files to speed up the loading process?
>>> Garbage.
>>> What it will do, if done properly, is speed up the initial
>>> rendering of the page. But it WON'T speed up load time of the
>>> files and will actually slow it down. The reason it will
>>> actually slow it down is because it has to do more work to
>>> load the files. Whether the file is static coded or dynamically
>>> loaded, the file still has to be downloaded from the server.
>>> Want it to download faster? Make the file physically smaller.
>>> Any other advice is magical hocus-pocus for making it load
>>> faster if everything else is the same.
>>> (...)

>> I'm not sure why do you say so, as it's obvious (isn't it ?) that
>> latency times add up when the scripts are loaded in series.

>
> I say that because its patently true. Unless you want to try to
> convince me that connection speed is determined by how the file
> was attempted to be loaded. Again, take a HARD look at the original
> script, how it was written, and how it would work. Then let's
> discuss what it will or won't do.


<script>s hardcoded in the source .html halt parsing and download in
series, while dynamically inserted ones don't halt parsing and download
in parallel.

>> And for servers that throttle downloads (more and more each day, e.g.
>> youtube, me.com...), the time to download n scripts in parallel is not
>> necessarily === n* the time to download a single one.

>
> How a file is called is irrelevant to the amount of time it takes to
> download that file.


It isn't, see above.

> IE is notorious for loading multiple files at once
> irregardless of how you try to load it.



> For a file that is of size S, it will take a given amount of time T,
> to
> download the file from the server *irregardless of how its requested*
> if
> all other parameters are equal. Same network speed, same processes on
> the
> computer making the request, same server load.


We're talking about parallel download therefore we're talking of
several, more than one files.

> The difference it makes is the appearance of loading faster by
> rendering
> the HTML aspects of the page first.
>
> Has John Resig gotten any clue about JS in the last 18 months or so?
> If he hasn't, then he still doesn't have a clue.


DM in disguise ?

--
Jorge.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      06-29-2009
On Jun 28, 9:57*pm, Jorge <(E-Mail Removed)> wrote:
> One Dumm Hikk wrote:
> > On Jun 27, 9:39 am, Jorge <(E-Mail Removed)> wrote:
> >> On Jun 27, 10:42 am, Gregor Kofler <(E-Mail Removed)> wrote:

>
> >>> (...)
> >>> As Jorge already mentioned:http://www.youtube.com/watch?v=52gL93S3usUandthe"degrading script
> >>> pattern" - it escapes me where the actual problem is, requesting sucha
> >>> bizarre "solution".
> >> The problem is:

>
> >> - Given a script that has not been loaded yet (still loading), -
> >> usually a dynamically inserted one-,
> >> - Find the best way to have some piece of code run asap, immediatly
> >> after the script (above) has loaded and executed.

>
> >> (note that "onload" is not -usually- available on <script> tags in
> >> most browsers)

>
> > That is trivial to do. Again, people try to make this stuff
> > harder than it has to be. Want a fool proof way to make a script
> > in an external file execute and know that is has loaded? Search
> > the archives, I have shown this MANY times and it was even before
> > many people knew JRs name.
> > At the end of the external file, place the call to the function
> > that you want executed.

>
> Yes we do that in e.g. every JSONP response.


Good for you.

>
> *> It will NOT get executed until the file
>
> > is loaded and it will get called only when the file gets loaded.
> > Stop making this harder than it has to be. Sheesh people.

>
> That f() must be a global and requires a previous, separate <script>.
> Resig's solution requires none of these.


Resig has no solutions, only snake oil. You are the only one in here
stupid enough to miss that.

>
>
>
> > On Jun 27, 10:30 am, Jorge <(E-Mail Removed)> wrote:
> >> On Jun 27, 3:49 am, One Dumm Hikk <(E-Mail Removed)> wrote:
> >>> Dynamically loading script files to speed up the loading process?
> >>> Garbage.
> >>> What it will do, if done properly, is speed up the initial
> >>> rendering of the page. But it WON'T speed up load time of the
> >>> files and will actually slow it down. The reason it will
> >>> actually slow it down is because it has to do more work to
> >>> load the files. Whether the file is static coded or dynamically
> >>> loaded, the file still has to be downloaded from the server.
> >>> Want it to download faster? Make the file physically smaller.
> >>> Any other advice is magical hocus-pocus for making it load
> >>> faster if everything else is the same.
> >>> (...)
> >> I'm not sure why do you say so, as it's obvious (isn't it ?) that
> >> latency times add up when the scripts are loaded in series.

>
> > I say that because its patently true. Unless you want to try to
> > convince me that connection speed is determined by how the file
> > was attempted to be loaded. Again, take a HARD look at the original
> > script, how it was written, and how it would work. Then let's
> > discuss what it will or won't do.

>
> <script>s hardcoded in the source .html halt parsing and download in
> series, while dynamically inserted ones don't halt parsing and download
> in parallel.


Re-read the thread from the beginning.

>
> >> And for servers that throttle downloads (more and more each day, e.g.
> >> youtube, me.com...), the time to download n scripts in parallel is not
> >> necessarily === n* the time to download a single one.

>
> > How a file is called is irrelevant to the amount of time it takes to
> > download that file.

>
> It isn't, see above.


Or just read what you quote.

>
> > IE is notorious for loading multiple files at once
> > irregardless of how you try to load it.
> > For a file that is of size S, it will take a given amount of time T,
> > to
> > download the file from the server *irregardless of how its requested*
> > if
> > all other parameters are equal. Same network speed, same processes on
> > the
> > computer making the request, same server load.

>
> We're talking about parallel download therefore we're talking of
> several, more than one files.


Randy knows what he is talking about. You haven't got the slightest
clue.

>
> > The difference it makes is the appearance of loading faster by
> > rendering
> > the HTML aspects of the page first.

>
> > Has John Resig gotten any clue about JS in the last 18 months or so?
> > If he hasn't, then he still doesn't have a clue.

>
> DM in disguise ?


See what I mean?
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      06-29-2009
Conrad Lender wrote:
> On 27/06/09 10:01, Garrett Smith wrote:
>> <FAQENTRY>
>> Q: I saw a video online. Why wasn't it in the FAQ?
>> A: Video presentations often contain advice that is either
>> incorrect or inadvisable. It possible, though unlikely, that the video
>> has not been reviewed and contains accurate and valuable information.
>> Before posting a request for review, please search the archives for
>> discussion about the video.
>> </FAQENTRY>

>
> I don't think that's necessary. The only person who frequently asked
> this question is Jorge, and he won't need an FAQ entry about it. He's
> promoting some links/videos which he considers valuable, and I don't
> think he'll stop until he receives a plausible explanation.
>
> Jorge, I see what you're doing, and I understand the motivation, but
> adding the same list of links after every repost of FAQ 3.2 isn't going
> help much. I suggest you make a separate post about these links, and ask
> why they shouldn't be included in the FAQ. Maybe we'll get some kind of
> review out of that thread.


They've got "their" own FAQ, I've got my own posts...

> Personally, I've become a bit disillusioned
> by Douglas Crockford's idea of the "Good Parts" of JavaScript. This is
> mostly due to what I've seen on the JSLint mailing list.


Why ?

>> Steve:

> ....
>> | I get all the script elements, I loop through them, until I find the
>> | script whose name is "menu jay", "menu-degrading.js" and then I look
>> | at its innerHMTL property.

>
> Thanks for transcribing the video, but usually bloopers are ommitted
> from a transcription. Reproducing them verbatim ("menu jay") doesn't
> really serve any purpose, unless you want to discredit the speaker.
> Giving a presentation without making mistakes is a LOT harder that
> writing a piece of text.
>
>> None of the three reasons is true. All are blatantly false and in being
>> false, they serve as reasons for eschewing this technique.

>
> JFTR, I don't recommend this technique either. The fact that it's
> invalid HTML


Is it ? Sure ? it's got text content not markup... (?)

> is reason enough for me. (...)


--
Jorge.
 
Reply With Quote
 
One Dumm Hikk
Guest
Posts: n/a
 
      06-29-2009
On Jun 28, 9:57*pm, Jorge <(E-Mail Removed)> wrote:
> One Dumm Hikk wrote:
> > On Jun 27, 9:39 am, Jorge <(E-Mail Removed)> wrote:
> >> On Jun 27, 10:42 am, Gregor Kofler <(E-Mail Removed)> wrote:

>
> >>> (...)
> >>> As Jorge already mentioned:http://www.youtube.com/watch?v=52gL93S3usUandthe"degrading script
> >>> pattern" - it escapes me where the actual problem is, requesting sucha
> >>> bizarre "solution".
> >> The problem is:

>
> >> - Given a script that has not been loaded yet (still loading), -
> >> usually a dynamically inserted one-,
> >> - Find the best way to have some piece of code run asap, immediatly
> >> after the script (above) has loaded and executed.

>
> >> (note that "onload" is not -usually- available on <script> tags in
> >> most browsers)

>
> > That is trivial to do. Again, people try to make this stuff
> > harder than it has to be. Want a fool proof way to make a script
> > in an external file execute and know that is has loaded? Search
> > the archives, I have shown this MANY times and it was even before
> > many people knew JRs name.
> > At the end of the external file, place the call to the function
> > that you want executed.

>
> Yes we do that in e.g. every JSONP response.
>
> *> It will NOT get executed until the file
>
> > is loaded and it will get called only when the file gets loaded.
> > Stop making this harder than it has to be. Sheesh people.

>
> That f() must be a global and requires a previous, separate <script>.
> Resig's solution requires none of these.


Pure nonsense. It doesn't have to be global nor does it
"require a previous, seperate <script>".
f() can be a property of a single global object and the call
can be made in the same file that you are loading. I know that
to be true because its the way I have been doing it for many
years now. Download a .js file that has data in it with a
function call at the end of the file that deals with the
data in the file. That is how you deal with the issue of
knowing when/if the file is downloaded or not. It is
the ONLY *reliable* way to know that the data file has
downloaded.

Perhaps you should search the c.l.j archives for
"dynamic script insertion" and spend the next two
weeks or so reading the many many threads on this
topic.

> > On Jun 27, 10:30 am, Jorge <(E-Mail Removed)> wrote:
> >> On Jun 27, 3:49 am, One Dumm Hikk <(E-Mail Removed)> wrote:
> >>> Dynamically loading script files to speed up the loading process?
> >>> Garbage.
> >>> What it will do, if done properly, is speed up the initial
> >>> rendering of the page. But it WON'T speed up load time of the
> >>> files and will actually slow it down. The reason it will
> >>> actually slow it down is because it has to do more work to
> >>> load the files. Whether the file is static coded or dynamically
> >>> loaded, the file still has to be downloaded from the server.
> >>> Want it to download faster? Make the file physically smaller.
> >>> Any other advice is magical hocus-pocus for making it load
> >>> faster if everything else is the same.
> >>> (...)
> >> I'm not sure why do you say so, as it's obvious (isn't it ?) that
> >> latency times add up when the scripts are loaded in series.

>
> > I say that because its patently true. Unless you want to try to
> > convince me that connection speed is determined by how the file
> > was attempted to be loaded. Again, take a HARD look at the original
> > script, how it was written, and how it would work. Then let's
> > discuss what it will or won't do.

>
> <script>s hardcoded in the source .html halt parsing and download in
> series, while dynamically inserted ones don't halt parsing and download
> in parallel.


And that is precisely what I said. It doesn't change the download time
it
takes, it changes the rendering time to render an initial page so that
you fool the uneducated into thinking the page has finished "loading"
because they see content. Witness mySpace and its abominable use of
AJAX to try to "speed up" the site when in fact its a classic example
of the *wrong way* to speed up a site.

> > Has John Resig gotten any clue about JS in the last 18 months or so?
> > If he hasn't, then he still doesn't have a clue.

>
> DM in disguise ?


That question, in and of itself, displays your level of knowledge
of what you are attempting to discuss. Try searching the archives
for the suggested search, read it all, and then get back to me.
Because as it stands now, your question shows that you have made
no effort to research the archives to find out about the subject
you are trying to portray yourself as an expert on.

I am not what I would consider an "expert" on the topic but I simply
have done a TON of research in the last 10 years or so on the topic
and a perusal of the archives would answer many of the questions you
are trying to - incorrectly - answer.

--
Randy Webb
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      06-29-2009
On Jun 29, 8:11 am, One Dumm Hikk <(E-Mail Removed)> wrote:
> On Jun 28, 9:57 pm, Jorge <(E-Mail Removed)> wrote:
> (...)
> > That f() must be a global and requires a previous, separate <script>.
> > Resig's solution requires none of these.

>
> Pure nonsense. It doesn't have to be global nor does it
> "require a previous, seperate <script>".
> f() can be a property of a single global object and the call
> can be made in the same file that you are loading. I know that
> to be true because its the way I have been doing it for many
> years now. Download a .js file that has data in it with a
> function call at the end of the file that deals with the
> data in the file.


Yes, the properties you attach to a global object are global too.
And yes, f() must have been declared somewhere (in a previous,
separate <script>) before calling it.

> That is how you deal with the issue of
> knowing when/if the file is downloaded or not. It is
> the ONLY *reliable* way to know that the data file has
> downloaded.
>
> Perhaps you should search the c.l.j archives for
> "dynamic script insertion" and spend the next two
> weeks or so reading the many many threads on this
> topic.


You mean, that perhaps, I'd find there something else that's not being
said here ?
A secret or something ?

> > > On Jun 27, 10:30 am, Jorge <(E-Mail Removed)> wrote:
> > >> On Jun 27, 3:49 am, One Dumm Hikk <(E-Mail Removed)> wrote:
> > >>> Dynamically loading script files to speed up the loading process?
> > >>> Garbage.
> > >>> What it will do, if done properly, is speed up the initial
> > >>> rendering of the page. But it WON'T speed up load time of the
> > >>> files and will actually slow it down. The reason it will
> > >>> actually slow it down is because it has to do more work to
> > >>> load the files. Whether the file is static coded or dynamically
> > >>> loaded, the file still has to be downloaded from the server.
> > >>> Want it to download faster? Make the file physically smaller.
> > >>> Any other advice is magical hocus-pocus for making it load
> > >>> faster if everything else is the same.
> > >>> (...)
> > >> I'm not sure why do you say so, as it's obvious (isn't it ?) that
> > >> latency times add up when the scripts are loaded in series.

>
> > > I say that because its patently true. Unless you want to try to
> > > convince me that connection speed is determined by how the file
> > > was attempted to be loaded. Again, take a HARD look at the original
> > > script, how it was written, and how it would work. Then let's
> > > discuss what it will or won't do.

>
> > <script>s hardcoded in the source .html halt parsing and download in
> > series, while dynamically inserted ones don't halt parsing and download
> > in parallel.

>
> And that is precisely what I said. It doesn't change the download time
> it
> takes, it changes the rendering time to render an initial page so that
> you fool the uneducated into thinking the page has finished "loading"
> because they see content.


Now it looks like you're focusing on the "doesn't halt parsing" aspect
while conveniently forgetting about the "and download in parallel
(read: faster)" side of things.

> Witness mySpace and its abominable use of
> AJAX to try to "speed up" the site when in fact its a classic example
> of the *wrong way* to speed up a site.
>
> > > Has John Resig gotten any clue about JS in the last 18 months or so?
> > > If he hasn't, then he still doesn't have a clue.

>
> > DM in disguise ?

>
> That question, in and of itself, displays your level of knowledge
> of what you are attempting to discuss. Try searching the archives
> for the suggested search, read it all, and then get back to me.
> Because as it stands now, your question shows that you have made
> no effort to research the archives to find out about the subject
> you are trying to portray yourself as an expert on.


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

> I am not what I would consider an "expert" on the topic but I simply
> have done a TON of research in the last 10 years or so on the topic
> and a perusal of the archives would answer many of the questions you
> are trying to - incorrectly - answer.
>
> --
> Randy Webb


--
Jorge.
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      06-29-2009
Conrad Lender wrote:
> On 27/06/09 10:01, Garrett Smith wrote:
>> AISB, eval is called in global context. Steve did not mention this, and

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> the code is so naive that I doubt he is even aware of it, but the code
>> must exist in global context, or use a separate sandbox function.

>
> What's so bad about a calling a separate function to do the eval()? This
> will make sure that the JS string is always evaluated in global context,

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

> and it also keeps the 'eval' out of the loader code, which makes
> minification easier:
>
> function evil (code) {
> return eval(code);


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.

function isMethod(o, p)
{
if (/^\s*(undefined|unknown)\s*$/i.test(typeof o)) return false;

var t = typeof o[p];
return (/^\s*unknown\s*$/i.test(t)
|| /^\s*(function|object)\s*$/i.test(t) && o[p]);
}

function dmsg(s, bShow)
{
if (typeof console != "undefined"
&& isMethod(console, "log"))
{
console.log(s);
}
else if (bShow
&& typeof window != "undefined"
&& isMethod(window, "alert"))
{
window.alert(s);
}
}

function evil(code)
{
var result = eval(code);

/* 1. typeof x === "number" */
dmsg('1. typeof x === "' + typeof x + '"', true);

/* 2. typeof y === "number" */
dmsg('2. typeof y === "' + typeof y + '"', true);

delete x;

/* 3. typeof x === "undefined" */
dmsg('3. typeof x === "' + typeof x + '"', true);

/* 4. typeof y === "number" */
dmsg('4. typeof y === "' + typeof y + '"', true);

return result;
}

/* 5. evil(...) === 42 */
dmsg('5. evil(...) === ' + evil("var x = 1, y = 2; 42"), true);

/* 6. typeof y === "undefined" */
dmsg('6. typeof y === "' + typeof y + '"', true);


PointedEars
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Using Web.config's <system.web><pages><controls><add /></controls></pages></system.web> To Register UserControls Nathan Sokalski ASP .Net 5 01-10-2007 10:50 AM
Using Web.config's <system.web><pages><controls><add /></controls></pages></system.web> To Register UserControls Nathan Sokalski ASP .Net Web Controls 4 12-21-2006 02:50 AM
Using Web.config's <system.web><pages><controls><add /></controls></pages></system.web> To Register UserControls Nathan Sokalski ASP .Net Building Controls 4 12-21-2006 02:50 AM
Dynamic loading of Web User Controls into a Content/ContentPlaceHo =?Utf-8?B?V291dGVy?= ASP .Net 1 02-25-2006 07:37 PM
Availability of Dynamic Architect - Build advanced dynamic web pages without code! jonjon Javascript 0 10-29-2003 10:10 PM



Advertisments