Re: John Resig Video

Richard Cornford wrote:
Garrett Smith wrote:
Richard Cornford wrote:
Garrett Smith wrote:




Modern browsers perform parallel downloads.

Non-modern browsers probably also do/did that, subject to simultaneous HTTP connection constraints.

The resources are downloaded asynchronously, interpreted in
sequential order.

But which sequential order; the order in which they are requested, the order in which they start to arrive or the order in which they finish

None of the above. They are interpreted in the order in which they appear in the source code.

<script src="a.js"></script>
test
<script src="b.js"></script>

a.js must be executed first.


arriving? Granted you cannot do the execution for the global execution context until the entire source code ahs been received (because variable instantiation may be inflamed by even the last line of code to arrive) but you certainly can tokenise and parse as the source code is delivered.

The HTML 5 draft proposes an async attribute[1]:-
| If the async attribute is present, then the script will be
| executed asynchronously, as soon as it is available.

That fulfills the "doesn't matter when it executes" statement.

In what sense?


What 'async' means is that b.js could run first. The order is unimportant.

The order scripts are executed matters very much.

Can "matter very much", even 'usually matters very much', but
there are scripts for which it doesn't matter at all.

Sure. It can go either way. The result of executing of a deferred script would usually be different.

There is something missing from that last statement.


[from executing that same script non-deferred].

<script src="p.js"></script>
<script src="q.js"></script>

Adding "defer" to p.js would likely have a different result.

Deferred scripts have an execution order.

But not any sort of specified execution order. Just the order in
which particular instances of browser software can be observed to
execute them.

That order is not stated by the specification,

There you go.

but IE does execute the scripts in a certain order.

It is not in the nature of computer software to do this sort of
thing randomly. It is certain that what IE does with a deferred
script could be expressed in terms of an algorithm, and likely
that the outcome of applying that algorithm will be consistent,
predictable and systematic.

The async attribute allows the browser to run the script when
it is loaded. The defer attribute is implemented to preserve
a particular order.

How something has been implemented only says so much about how it may be implemented.


I think "only" is too strong a word here. Where compatibility is desired, other browsers might copy that implemented behavior. The use of of that thing's unspecified features can influence other implementations to follow suit.

https://bugzilla.mozilla.org/show_bug.cgi?id=28293#c19

The spec is silent about the order. IE does have an order. Order matters.

https://bugzilla.mozilla.org/show_bug.cgi?id=28293

Comments 19, 31, 35 are interesting. Comments 63 and 64 took the author 1 year to change his mind.

Firefox 3.1pre (current) has a working implementation of defer.

The download of the resource is not coupled to its execution.

Beyond being a necessary pre-requisite.

The defer does attribute not indicate execution order. Non-deferred scripts are executed in order; deferred scripts are executed when
the DOM is ready.

Ready for what? You risk ending up with a definition of "ready" that means no more than that deferred scripts are executed when they are executed. If the browser finishes parsing the HTML, building the DOM, executing inline scripts, etc, before the deferred script has finished downloading then doesn't it still have to wait before it gets executed? And in environments were defer is not implemented that same script is going to processed inline and so be executed before the DOM is complete, which could still happen even if defer is implemented as "can continue parsing ..." does not say 'MUST continue parsing ... ' or deny the possibility of the script being executed asynchronously by a separate thread while the parser continues parsing.


For implementations that support defer, those scripts run only after the document is parsed and rendered. When the "DOMContentLoaded" event (Gecko, Opera), and document.readyState (Webkit) fires is not guaranteed.

There is not a standard that defines the order for deferred scripts.

Both order and timing are left open-ended by the HTML specification. Thus the only rational response would be to only use DEFER with scripts where neither matter.


Other browsers' documentation should also be considered. If there is a webkit bug and a Mozilla bug and they agree on copying IE, and the respective implementations do copy IE, and Opera copies IE, would that not be enough?

Defer is is not implemented in many recent, modern browsers. Adding defer attribute to a script will likely result in the program behaving differently.

What IE does with inline scripts is weird/complicated.

From some perspective or another, everything web browsers do is weird and/or complication, but little is gained by saying just that.


Apparently, inline deferred scripts execute before the external deferred scripts, regardless of source order.

http://www.websiteoptimization.com/speed/tweak/defer/


The meaning of "location" could be "order in the html source" or "window.location". I think I got what he meant.

But you are not going to say what that was?


I did say so below.

[...]

Here:


When he said "correct location," I think he meant, "where
document.write would normally go to" (in a non-deferred script).

However, John should already know that it does not work that way.

Or at lest be able to see how very unlikely it would that things could work in that way.


To make such statements, one would have to be completely oblivious to what the defer attribute does or can do.


That was 2006. It is been three years and a lot of c.l.js
criticism later.

You don't have to have that much actual knowledge to see that the relationship between the first assertion and the second in no way warrants a "since" attempting to link the two.

He is still saying stuff that appears to be totally made up.

Is "made up" an appropriate way of labelling a misconception? It implies deliberate intent. It is hard to see how anyone could believe they could get away with that in a technical field where facts can be objectively verified/refuted. And what would be to gain?


I suppose it is possible that he does not know that he does not know what defer is.

"Can be refuted" and "are refuted" are different things. When said facts are refuted, those refutations can be interpreted as hostile, even if they are carefully worded to not appear so.

When the misconception receives a majority of replies such as "awesome post", it is not hard for the casual reader dismiss the one long-winded argument.

Garrett

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
.

Relevant Pages

  • Re: WMF Windows security flaw - change your browser
    ... So there is no need for them to have a WMF extension. ... people were pulling was to name an executable file with an extension that sends them someplace where they'll be opened automatically, which starts executing them. ... The capabilities of the scripts are quite limited, ... So they simply put the malicious code into the WMV file (Windows just assumes that it IS graphic data), then use the buggy scripting DLL to branch to it. ...
    (rec.audio.pro)
  • Re: More than one vbs file
    ... but most languages have such a funcion so I was very suprised. ... between including code from another source and executing code from another ... In the assemblers I mentioned, ... Since I wrote our scripts, I am the one that gets the call ...
    (microsoft.public.scripting.vbscript)
  • Problems with make -j
    ... As a pet project I've started to change /etc/rc so it uses maketo ... up boot time by executing rc.d scripts in parallel. ...
    (freebsd-questions)
  • Re: Reasons for inittab process not starting
    ... I don't know of any system logs per say, ... redirect the output of the scripts being executed to a file: ... That will put the output of the executing script ... > From: IBM AIX Discussion List ...
    (AIX-L)
  • Re: JScript download stops others?
    ... page rendering you should use the Defer attribute which ... includes a web interface littered with deferred scripts. ... This seems independent of user-initiated events, and we suspect the DEFER ... Unsolicited commercial email will be read at a cost of $500 per message. ...
    (microsoft.public.scripting.jscript)