Re: John Resig Video

Richard Cornford wrote:
Garrett Smith wrote:
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.

The statement I was commenting on came at the end of a paragraph that commenced "The defer attribute tells the parser that it can continue downloading and rendering the page", so an example that does not feature the DEFER attribute seems to serve no purpose as a clarification of what you were talking about.

<snip>
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.

That would be a reasonable interpretation of asynchronous.


In a general sense, one implication of the word 'asynchronous' would be
'a could run first'. I'm talking about the async attribute, specifically
here.


The order is unimportant.

The order is uncertain. But what has that to with fulfilling the "doesn't matter when it executes" statement?


If the program does not rely on order of scripts, it can load and
execute them asynchronously.

It would be somewhat desirable to have better control over script
loading. In order to process a resource, it must first be loaded.

The scripts are normally declared in the HTML, the browser loads them when it thinks it should (depends on browser) and, if the resource is not deferred, executes it in order (of appearance in the document).

If the resource is deferred, then it would execute after the page has been rendered. (though nonstandard, this is the way IE has handled defer for many years)[1].

If the async attribute is present, then the script will execute as soon as it is available. (Running an async script before that part of the document has rendered would seem to be highly undesirable, but that is what Ian has decided to require).

<snip>
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.

Yes they might, but expecting them to without any better reason would be reckless.


A better reason such as broad use? How about what MSDN says and what IE has done for years? Not enough?

I suspect defer would be more commonly used on closed IE-only applications than on public sites.

<snip>
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.

That is just an observation about specific implementations.


The statement 'those scripts run only after the document is parsed and
rendered' is based on what IE does explicitly, by design. For an
implementation to design a new implementation of DEFER that it is
executed before the document is rendered would not give anyone and
advantage; it would be pointless.


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?

For an intranet application with known and fixed expectations of browsers that are to be used with the application. For general cross-browser code that assumption is little better than "this site is best viewed with IE" or the "both browsers" attitudes of the turn of the century.

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

Differently from what? If a DEFER attribute is only ever added to a SCRIPT element for which the time of execution of the corresponding script does not matter at all then the overall outcome should not be different at all.


Reworded:
If a DEFER attribute is only ever added to a SCRIPT element for which
the *order* of execution of the corresponding script does not matter at
all then the overall outcome should not be different at all.

Observable differences become noticeable with network latency for that
script or for a style*** in that page.

For example:-

<script defer src="a" type="text/javascript"></script>
<link type="text/css" rel="style***" href="b">

If defer is not implemented, the script runs before b loads. Otherwise,
the opposite may be true (Firefox 3.1 DEFER'd script waits for link to
finish[2]). This affects page rendering and what is displayed and how/where.

In firefox <= 3.x, a script that follows a style*** will not load
until the style*** loads.

If the script is DEFER'd, the actions the browser takes in loading and
rendering the page will differ between non-DEFER'd and DEFER'd in
implementations.

There is no way to declare dependency of a script. The order that
resources are loaded varies in implementations.

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.

Differently from what? If a DEFER attribute is only ever added to a SCRIPT element for which the time of execution of the corresponding script does not matter at all then the overall outcome should not be different at all.


Did you want to say something else?

<snip>
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.

To make such a statement while maintaining your interpretation of "correct location". With an alternative meaning the statement containing "correct location" could become less technically objectionable.


I cannot think of a plausible alternative meaning.

<snip>
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.

Entirely possible.


It might also be possible to decide to make a presentation on browser
performance, develop an outline, and then fill in the discussion with
"stuff like that."

"Can be refuted" and "are refuted" are different things.

But possibly only in short term.

When said facts are refuted, those refutations can be interpreted
as hostile,

Can be? They very often are.

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.

A rational person dismissing reasoned argument knows they are making a mistake. But demonstrations are harder to dismiss than arguments, and where the technical aspects of javascript and/or browser scripting is concerned the truth can always be demonstrated.


While your optimism is admirable, not one person is 100% rational.

It can be easier to dismiss a long-winded post than to copy-paste the example into an editor, run it, check the results. Not everyone has the time to do that; those who do might not have the technical ability to make judgments.

Richard.

Garrett

[1]http://msdn.microsoft.com/en-us/library/ms533719(VS.85).aspx
[2]http://dhtmlkitchen.com/jstest/block/link-defer-top.html
--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
.