Re: Dynamic loading of javascript files into web pages

On Jun 28, 5:45 pm, Conrad Lender <crlen...@xxxxxxxxx> 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.)
.

Relevant Pages

  • Re: Dynamic loading of javascript files into web pages
    ... I saw a video online. ... Why wasn't it in the FAQ? ... Video presentations often contain advice that is either ... requires more code inside menuteir.js to execute the inline script ...
    (comp.lang.javascript)
  • Re: please Help >>=> Windows Media Player cannot play this DVD bec
    ... The FAQ that Cody pointed you to was an incorrect reference contextually and inappropriate for DVD playback issues, as you probably noticed when there were no DVD issues covered in that FAQ. ... Does the video card vendor have an updated version available? ... Windows Media Player. ...
    (microsoft.public.windows.vista.general)
  • Re: Dynamic loading of javascript files into web pages
    ... I saw a video online. ... Why wasn't it in the FAQ? ... Moving the script to the bottom helps, ... it ought to mention that his application design advice is considerably harmful. ...
    (comp.lang.javascript)
  • Re: Dynamic loading of javascript files into web pages
    ... I saw a video online. ... Why wasn't it in the FAQ? ... Video presentations often contain advice that is either ... Before posting a request for review, please search the archives for discussion about the video. ...
    (comp.lang.javascript)
  • FAQ for the NewsGroup uk.gov.agency.csa
    ... Users of this newsgroup compile this FAQ in good faith. ... Who can I talk to for advice about dealing with the CSA? ...
    (uk.gov.agency.csa)
Loading