[Apologies for being out of the loop on this thread thus far, as I was one
of the main proponents of it earlier this year. I am now going to dive in
and offer some feedback, both to Ian's comments as well as to others that
have replied. I also apologize that this will be an exceedingly long
Sorry for repetition, but we can already preload images and CSS and apply
them to the page at an arbitrary point in time. Why wouldn't we want the
same thing for JavaScript?
I think the question is whether you want _more_ than that for JavaScript.
For images, you can preload them and choose
This isn't practical if the contents of the script are not under the
author's direct control. For example, an author that wanted to use jquery
would create a script tag with the src set to one of the popular jquery
mirrors (to maximize the chance of the resource being cached), but then have
no
If browsers processed (parsed compiled) scripts in a background thread
it would mitigate the problem, but not solve it. Suppose I have 100K of
JS I need right now to generate the DOM for the initial page, and I have
another 500K of JS that's only needed if the user clicks on FeatureX.
Assuming
I think there's a valid use case for downloading a script and not
evaluating it immediately.
I think we all agree on that.
Boris-
I wish that were true, at this point, but I'm not sure that it is. The tone
I got from Ian's post (and even subsequent replies) was that he in fact does
not see
On 5/27/11 1:10 PM, Aryeh Gregor wrote:
Also, consider a third possibility: currently, the part ofscript
async that's captured by the first timing in Ian's/Boris' example
(whether it's parsing or compilation or whatever) blocks the main
thread in browsers, even though it's async. (Right?)
On Thu, 26 May 2011, Boris Zbarsky wrote:
On 5/26/11 1:10 AM, Ian Hickson wrote:
It's presumably a whole heck of a lot more complex than brack matching:
alert('fail');
function test () {
// ...megabytes of perfectly fine code...
a b;
}
...had better not
On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
I'm a little surprised that this conversation has swooped back around to
performance and whether or not there's a valid use case here. In addition to
standalone solutions like Steve's ControlJS and Kyle's LABjs, the
On Thu, May 26, 2011 at 3:49 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas nza...@yahoo-inc.com
wrote:
I'm a little surprised that this conversation has swooped back around to
performance and whether or not there's a valid use case here. In
...@geekhood.net]
Sent: Tuesday, May 24, 2011 2:33 PM
To: whatwg@lists.whatwg.org
Cc: Nicholas Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Tue, 24 May 2011 17:34:45 +0100, Nicholas Zakas nza...@yahoo-inc.com
wrote:
Your assertion that loading a file that simply
On Tue, May 24, 2011 at 12:34 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
Moving parsing and compilation to a background thread solves part of the
problem, the problem where doing so freezes the UI currently. It doesn't
solve what I consider to be the important part of the problem, and
On Wed, May 25, 2011 at 8:05 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
There's a big conceptual difference between parsing the script and
executing it. We need to be careful not to conflate the two, even if
browsers don't *currently* separate them.
I just discussed this on IRC with
Hi Ian,
Thank you for all the time you're spent reading this thread.
My understanding right now is that:
- if we want a script to be downloaded without blocking the UI, we should use
async
- implementors shouldn't block the UI while parsing the JS (but it should
still respect the order of
On Tue, 24 May 2011 17:34:45 +0100, Nicholas Zakas nza...@yahoo-inc.com
wrote:
Your assertion that loading a file that simply defines a function will
solve the problem is a bit too simplistic for most web applications.
Could you describe the case where wrapping script in a function would
In many (all?) cases below the term execution is meant to include
parsing and compilation. I know that's what Nicholas and Kyle have in
mind, and is the motivation behind Gmail's comment hack and my ControlJS
library.
If browsers processed (parsed compiled) scripts in a background thread
it
: [whatwg] Proposal for separating script downloads and execution
On 3/3/11 5:20 AM, Henri Sivonen wrote:
Are there the known to be pages that users frequently encounter that create
and set src on a large number of script nodes without inserting them?
Not known to me, no. I've seen pages
On Fri, Mar 4, 2011 at 12:49 PM, Nicholas Zakas nza...@yahoo-inc.comwrote:
Okay, so it sounds like everyone is really much more in favor of an
approach that doesn't require execute() to run the code that was preloaded.
I'm not against execute() as such for a synchronous API, I just don't
Can someone double-check that onreadystatechange does not actually work
for
this in IE9 in standards mode? IE9 seems to no longer fire
onreadystatechange when the script is not in the document. (onerror is,
though, which I think is a spec violation.)
On Fri, Mar 4, 2011 at 3:04 PM, Kyle Simpson get...@gmail.com wrote:
Can someone double-check that onreadystatechange does not actually work for
this in IE9 in standards mode? IE9 seems to no longer fire
onreadystatechange when the script is not in the document. (onerror is,
though, which I
On 3/3/11 5:20 AM, Henri Sivonen wrote:
Are there the known to be pages that users frequently encounter that create and
set src on a large number of script nodes without inserting them?
Not known to me, no. I've seen pages that create lots of scripts (one
per each dynamic action they want
So, I'm just curious, what do the participants of this thread (and Ian,
specifically) feel is the most productive next step? We have 3 or 4
proposals that have all garnered various support. We've had at least one
browser-developer informing us on concerns with various aspects of each.
I have,
On Thu, 3 Mar 2011, Kyle Simpson wrote:
So, I'm just curious, what do the participants of this thread (and Ian,
specifically) feel is the most productive next step? We have 3 or 4
proposals that have all garnered various support. We've had at least one
browser-developer informing us on
So, I'm just curious, what do the participants of this thread (and Ian,
specifically) feel is the most productive next step? We have 3 or 4
proposals that have all garnered various support. We've had at least one
browser-developer informing us on concerns with various aspects of each.
As with
It seems like IE9 only fires onreadystatechange on scripts which aren't in
the document when in quirks mode. If the HTML5 doctype is present, it'll
still load scripts before inserting them into the document, but
onreadystatechange doesn't seem to be fired. Can someone confirm?
--
Glenn Maynard
-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Nicholas Zakas
Sent: Wednesday, February 23, 2011 2:44 PM
To: Boris Zbarsky; Jorge
Cc: whatwg@lists.whatwg.org; Glenn Maynard
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Wed, Mar 2, 2011 at 1:21 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
After chatting a bit with Boris, it seems important for implementation that
a script node is already in the DOM before download begins. Given that, it
seems like this proposal is closest to being implementable:
On 23/02/2011, at 04:57, Boris Zbarsky wrote:
On 2/22/11 10:42 PM, Glenn Maynard wrote:
Including execute() being synchronous, raising SyntaxError exceptions
for parse errors, and uncaught exceptions from the script being
propagated up through execute() to its caller?
Hmm. That last one
On Wed, Feb 23, 2011 at 10:16 AM, Jorge jo...@jorgechamorro.com wrote:
On 23/02/2011, at 04:57, Boris Zbarsky wrote:
On 2/22/11 10:42 PM, Glenn Maynard wrote:
Including execute() being synchronous, raising SyntaxError exceptions
for parse errors, and uncaught exceptions from the script being
I don't understand why the preloading specifically would imply different
HTTP caching semantics than normal dynamic script loading?
It doesn't have to. It's just that if preloading is easy to trigger by
accident and authors don't notice when they accidentally preload lots of
stuff then we may
On 2/23/11 4:16 AM, Jorge wrote:
Wouldn't this :
HTMLScriptElement.prototype.execute= function execute () {
// ...
return (1, eval)( this.innerText ); // global eval
}
do it ?
No. First of all, the script can be an external script, so innerText
doesn't do the right thing.
(only
On 2/23/11 8:33 AM, Kyle Simpson wrote:
I'm curious if we could apply some limit to the number of scripts that
will be simultaneously preloaded, at say 100 scripts for instance?
I would be fine with that from an implementation standpoint; not sure
about the author-facing aspect of it.
I'm curious if we could apply some limit to the number of scripts that
will be simultaneously preloaded, at say 100 scripts for instance?
I would be fine with that from an implementation standpoint; not sure
about the author-facing aspect of it.
As one of the concerned web-authors, I can't
Zbarsky
Sent: Wednesday, February 23, 2011 6:18 AM
To: Jorge
Cc: whatwg@lists.whatwg.org; Glenn Maynard
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On 2/23/11 4:16 AM, Jorge wrote:
Wouldn't this :
HTMLScriptElement.prototype.execute= function execute
Again, I think the spirit we all share is to find the simplest proposal
that gets the job done, and introducing a new .execute() concept raised
more questions than it purported to solve.
The last dozen or two messages were regarding your rabbit hole, which
raised serious issues.
Serious
On Thu, 2011-02-17 at 15:24 -0500, Boris Zbarsky wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for every script element?
For the most part this seems to be the case but there are two exceptions:
a) Before a URL loads, if it's assigned to another
On 2/22/11 1:25 PM, Will Alexander wrote:
On Thu, 2011-02-17 at 15:24 -0500, Boris Zbarsky wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two exceptions:
a)
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request is made.
OK, that would be a
On 2/22/11 1:50 PM, Kyle Simpson wrote:
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two
exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request
1) If your script is no-cache, or max-age:0, does IE make a new
request for it for everyscript element?
For the most part this seems to be the case but there are two
exceptions:
a) Before a URL loads, if it's assigned to another script, only one
request is made.
OK, that would be a violation
On 2/22/11 3:07 PM, Kyle Simpson wrote:
Look above at what Will says... he says before a URL loads in (a). I
interpreted that to mean that if I make two requests in rapid fire
succession, and the browser hasn't yet gotten the response headers (from
the first request) to tell it not to cache,
On Tue, Feb 22, 2011 at 4:13 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Uh... In that situation I would expect the event handler to
keep the script alive until the load finishes.
Anything else is just a bug that exposes GC timing to the web page.
Yes, quite strange. It's fixed in IE9 (at
On 2/22/11 6:21 PM, Will Alexander wrote:
Would a means by which authors can mark a pre-fetched script as
stale allay some of your concerns?
I wouldn't expect anyone to actually use such a means.
Is there some way to accomplish this in Gecko now for a pre-fetched Image?
If you hold a
But note that image loads very explicitly do NOT have HTTP semantics, last
I checked. In Gecko they coalesce very aggressively in a cache that sits
in front of the network layer, including coalescing across documents, etc.
This cache applies to both in-progress loads and completely loads (it's
On 2/22/11 6:39 PM, Kyle Simpson wrote:
This seems strange to me. Generated images (like in captchas, etc) have
to be common enough
The captchas I just looked at use different URIs for different captcha
images.
I oversimplified a bit: the image cache in Gecko does do some http-like
stuff,
This can cause the wrong image to show temporarily, until replaced by the
right one (which I consider a bug; I think the cache needs to be less
aggressive).
That approach is clearly not workable for scripts... ;)
No, clearly not. I think we're finally in agreement on something. :)
I think
On 2/22/11 7:19 PM, Kyle Simpson wrote:
For #1, I think we've established this is probably true (for those rare
corner cases). Perhaps a more sophisticated in-memory content-uniqueness
cache could be constructed, but it may be more work than it's worth. To
push the ball forward, in a rough
On Tue, Feb 22, 2011 at 6:35 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Would a means by which authors can mark a pre-fetched script as
stale allay some of your concerns?
I wouldn't expect anyone to actually use such a means.
Understandable.
I ask because at one point you stated if DOM
On Tue, Feb 22, 2011 at 8:14 PM, Kyle Simpson get...@gmail.com wrote:
First of all, which two proposals are we talking about here?
1. Nicholas' proposal, which is currently to preload a script if its
script element is marked with a `preload` attribute, before the setting of
the `src`
On 2/22/11 8:05 PM, Will Alexander wrote:
I ask because at one point you stated if DOM attachment triggers the
pre-load (instead of src assignment), that would address the memory
consumption.
Well, more precisely it would make it less likely that someone would
accidentally author broken
On 2/22/11 8:54 PM, Glenn Maynard wrote:
3. My (and Nicholas's previous) proposal: Script elements are fetched when
inserted into the DOM[1]. An event is dispatched when the script has been
fetched, eg. onfetch or onpreload[2]. A preload attribute is added;
when true, the script will not be
On Tue, Feb 22, 2011 at 9:24 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/22/11 8:54 PM, Glenn Maynard wrote:
3. My (and Nicholas's previous) proposal: Script elements are fetched when
inserted into the DOM[1]. An event is dispatched when the script has been
fetched, eg. onfetch or
On 2/22/11 9:55 PM, Glenn Maynard wrote:
The main arguments for the readyState approach over this have been: it's
what IE does now, and the preloading when src is set has precedent with
images.
I sympathize with that, since they're aiming to improve the likelihood of
being implemented--but the
On Tue, Feb 22, 2011 at 10:17 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I also think the other side benefits of this approach are significant, so
long as they don't make it too hard to implement. That really needs
implementor feedback--if you can give that, let me know if you want a more
On 2/22/11 10:42 PM, Glenn Maynard wrote:
Including execute() being synchronous, raising SyntaxError exceptions
for parse errors, and uncaught exceptions from the script being
propagated up through execute() to its caller?
Hmm. That last one might take some work in Gecko, if it's even sanely
Souders
Subject: Re: RE: [whatwg] Proposal for separating script downloads and execution
On Feb 15, 2011 6:34 PM, Nicholas Zakas
nza...@yahoo-inc.commailto:nza...@yahoo-inc.com wrote:
1) Should the default behavior for dynamic script nodes be to start
downloading the file upon the setting
On 2/17/11 11:07 AM, Nicholas Zakas wrote:
With regards to #1, I do think it could be user-agent defined if
agreement can’t be reached on the correct default behavior (so in IE
preload would default to true while in FF it would default to false).
That seems like a reasonable first step.
CCing
(so in IE preload would default to true while in FF it would default to
false).
Let's be clear. In Nicholas' proposal, while the `preload` property may
default to true or false, the property (I think confusingly misnamed)
controls a *behavior*, which is NOT binary true/false. The more
The problem with prefetching immediately on src set is that you have no
idea when or whether the node will get inserted. So you have to keep the
data alive... for how long? From a user's point of view, that's a memory
leak pure and simple, if the node never gets inserted into the DOM.
On 2/17/11 11:39 AM, Kyle Simpson wrote:
Memory leak in the sense that the page is holding onto more memory than
it *potentially* needs to. But not memory leak in the sense that this
memory stays around after the page unloads/reloads, right?
Right.
I dunno if
I'd call that a memory leak as
I dunno if
I'd call that a memory leak as much as I'd call it a higher memory
utilization, or maybe potential memory waste.
Most users will call continuously increasing memory (which is what you'd
get if a page creates script elements, sets src, and then doesn't insert
them, perhaps by
On 2/17/11 12:23 PM, Kyle Simpson wrote:
My worries are cases where a page inadvertently makes you hold on to
tens or hundreds of megabytes of js, not about the 200k case.
Do you have any example where hundreds of megabytes of JavaScript is
being loaded onto pages? Even tens of megabytes seems
Do you have any example where hundreds of megabytes of JavaScript is
being loaded onto pages? Even tens of megabytes seems quite
extraordinary.
Think 10,000 script elements all pointing to the same 25KB script. If
you're forced to preload the script at src-set time, that's 25MB of data.
And
On 2/17/11 2:38 PM, Kyle Simpson wrote:
I don't know of any browsers which are set to download more than 8
parallel connections.
You don't need it, if the content is cached, right?
I can't imagine that you'd have 10,000 separate
downloads of the same resource. Depending on race conditions,
Boris: The 2.0 preload proposal--not 2.1--avoids the preload issues
you're worried about, right? With that version, only script nodes in
the DOM tree are loaded.
Another issue: with the preload-when-not-in-DOM model, it's impossible
to listen for all script events by capturing them. To do
On 2/17/11 4:15 PM, Glenn Maynard wrote:
Boris: The 2.0 preload proposal--not 2.1--avoids the preload issues
you're worried about, right? With that version, only script nodes in
the DOM tree are loaded.
I've lost track of the various proposals, honestly. If only nodes in
the DOM are
On Feb 15, 2011 6:34 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
1) Should the default behavior for dynamic script nodes be to start
downloading the file upon the setting of src and only execute when added to
the document (IE's behavior) or not?
Could the default behavior be defined by the
On Wed, Feb 16, 2011 at 9:28 AM, Will Alexander
serverherder+wha...@gmail.com wrote:
In this bug report Boris Zbarsky expresses concern that prefetching without
creating memory leaks is difficult.
https://bugzilla.mozilla.org/show_bug.cgi?id=621553
Possibly related:
Although I'm not aware of anyone wrapping a 250KB style-sheet in
comments, the pre-loading interface could seemingly be applied to any
number of elements. Nicholas' original e-mail referenced a blog post
by Stoyan Stefanov which details a way to pre-fetch both scripts and
stylesheets.
It's
: Tuesday, February 15, 2011 3:29 PM
To: Will Alexander
Cc: Glenn Maynard; Nicholas Zakas; whatwg@lists.whatwg.org; Nicholas C. Zakas;
Steve Souders
Subject: Re: [whatwg] Proposal for separating script downloads and execution
Although I'm not aware of anyone wrapping a 250KB style-sheet
On Tue, Feb 15, 2011 at 6:33 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
That being said, I think we're going a bit off-track now. Both Kyle's and my
proposals are based on already-existing functionality that we know doesn't
break the web (code hacks aside). We'd both like to formalize
...@zewt.org]
Sent: Monday, February 14, 2011 1:37 AM
To: Kyle Simpson
Cc: Nicholas Zakas; whatwg@lists.whatwg.org; Nicholas C. Zakas; Will Alexander;
Steve Souders
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Sun, Feb 13, 2011 at 11:09 PM, Kyle Simpson
get
You may be correct in that people may never want to set preload to false.
You'll note that I put in my proposal that an alternate approach would be
for preload to be set to true by default.
Since your proposal also says that setting `preload` to `false` wouldn't do
anything except not
I've compiled a WHATWG Wiki page detailing both Nicholas' most recent (and
simplified) proposal (v2.1), as well as mine:
http://wiki.whatwg.org/wiki/Script_Execution_Order_Control
In essence, the two are somewhat converging, though are still distinct in
important ways. Nicholas's proposal now
On Sun, Feb 13, 2011 at 6:44 PM, Kyle Simpson get...@gmail.com wrote:
I've compiled a WHATWG Wiki page detailing both Nicholas' most recent (and
simplified) proposal (v2.1), as well as mine:
http://wiki.whatwg.org/wiki/Script_Execution_Order_Control
In essence, the two are somewhat
This change wasn't mentioned here, and introduces a lot of problems.
- script onerror is only dispatched for fetch errors, not syntax errors,
which makes error detection harder.
- If the called script throws an exception, the synchronous execute()
model allows the exception to be raised by
On Sun, Feb 13, 2011 at 11:09 PM, Kyle Simpson get...@gmail.com wrote:
You seem to suggest this is a bad thing. I actually think it's a good
thing that we're keeping script execution as much as possible in the
existing architecture. There's lots of different reasons why the queues and
On Fri, Feb 11, 2011 at 7:31 PM, Glenn Maynard gl...@zewt.org wrote:
I think the example code can be simplified a lot to demonstrate the API
more clearly. I've attached a simplified version. It also explicitly
catches exceptions from execute() and calls errorCallback, and demonstrates
: whatwg@lists.whatwg.org; Bjoern Hoehrmann
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Fri, Feb 11, 2011 at 5:51 AM, Boris Zbarsky bzbar...@mit.edu wrote:
I don't think so. If there is any parse or compilation or whatever you want
to call it error, the script
On 02/11/2011 04:40 PM, Nicholas Zakas wrote:
We've gone back and forth around implementation specifics, and now
I'd like to get a general feeling on direction. It seems that enough
people understand why a solution like this is important, both on the
desktop and for mobile, so what are the next
On Feb 11, 2011 12:31 PM, Will Alexander serverher...@gmail.com wrote:
On Feb 11, 2011 10:41 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
We've gone back and forth around implementation specifics, and now I'd
like to get a general feeling on direction. It seems that enough people
On Feb 11, 2011 10:41 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
We've gone back and forth around implementation specifics, and now I'd like
to get a general feeling on direction. It seems that enough people understand
why a solution like this is important, both on the desktop and for
We've gone back and forth around implementation specifics, and now I'd
like to get a general feeling on direction. It seems that enough people
understand why a solution like this is important, both on the desktop and
for mobile, so what are the next steps?
Are there changes I can make to my
On Fri, Feb 11, 2011 at 12:57 PM, Will Alexander
serverherder+wha...@gmail.com wrote:
Are there changes I can make to my proposal that would make it easier to
implement and therefore more likely to have someone take a stab at
implementing?
I may have missed it, but what would execute() do
...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Will Alexander
Sent: Friday, February 11, 2011 12:58 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Feb 11, 2011 10:41 AM, Nicholas Zakas nza...@yahoo-inc.com wrote
Simpson
Sent: Friday, February 11, 2011 3:42 PM
To: whatwg@lists.whatwg.org
Cc: Will Alexander; Nicholas C. Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution
We've gone back and forth around implementation specifics, and now I'd
like to get a general feeling
Once again, the problem with changing how src works is that there's no way
to feature detect this change. It's completely opaque to developers and
therefore not helpful in solving the problem.
I still believe the feature-detect for my proposal is valid. It's obviously
not ideal (often times
: [whatwg] Proposal for separating script downloads and
execution
On Feb 11, 2011 10:41 AM, Nicholas Zakas nza...@yahoo-inc.com wrote:
We've gone back and forth around implementation specifics, and now I'd
like to get a general feeling on direction. It seems that enough people
understand why
Note that there's still concern that the feature in general hasn't been
justified properly. In particular, the major real-world example used to
justify this is the Gmail scripts-in-comments hack, and I don't think we
actually know the complete justification for that. We know it's for mobile
]
On Behalf Of Glenn Maynard
Sent: Wednesday, February 09, 2011 7:43 PM
To: Kyle Simpson
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson get...@gmail.com wrote:
The original proposal is in fact more
* Kyle Simpson wrote:
For the purposes of this discussion, we are combining (but safely so, I
believe) execution and parsing, and saying that we want to be able to
defer the parse/execution phase of script loading. The reason it's
necessary to draw the distinction (and point out that parsing is
On 2/10/11 3:23 PM, Bjoern Hoehrmann wrote:
There are multiple phases between receiving bytes on the wire and having
executed the code they represent. Parsing would seem unlikely to be the
main problem here (parsing is mainly checking for syntax errors while or
after removing the character
For the purposes of this discussion, we are combining (but safely so, I
believe) execution and parsing, and saying that we want to be able to
defer the parse/execution phase of script loading. The reason it's
necessary to draw the distinction (and point out that parsing is the
costly
bit) is to
On Thu, Feb 10, 2011 at 12:53 PM, Kyle Simpson get...@gmail.com wrote:
For the purposes of this discussion, we are combining (but safely so, I
believe) execution and parsing, and saying that we want to be able to
defer the parse/execution phase of script loading. The reason it's
necessary to
On Thu, 10 Feb 2011 21:02:43 -, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Nope, execution is the culprit here, as function declarations are
actually executed code. Saying function foo() { bar(); } is the
same as saying window.foo = function(){ bar(); }; (module a few
irrelevant
* Boris Zbarsky wrote:
On 2/10/11 3:23 PM, Bjoern Hoehrmann wrote:
There are multiple phases between receiving bytes on the wire and having
executed the code they represent. Parsing would seem unlikely to be the
main problem here (parsing is mainly checking for syntax errors while or
after
On Thu, Feb 10, 2011 at 5:09 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
Yes, but it's a long way from there to saying that parsing must be a-
voided because parsing is inherently slow. As it becomes more common to
load very large libraries where you don't actually use most things, or
use
On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson get...@gmail.com wrote:
readyState
There's one other fundamental limitation of the readyState approach which I
forgot about: it's impossible to defer execution of inline scripts. It
inherently only works for external scripts. script noexecute can
Testing this shows that IE9 doesn't fire a progress event for the
transition that is of interest for the use case. That is, when the script
transitions to loaded, there's no event. Once the script has been
evaluated, there is a (rather useless) progress event for the transition
to complete. The
* John Tamplin wrote:
This is all arguing about semantics. The point is the current mechanisms
for handling scripts are insufficient, and on mobile phones in particular
the process of reading the contents of a script tag (whether you call that
parsing, executing definitions, or whatever), is way
On Thu, Feb 10, 2011 at 7:39 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
While I am sure that people here have done far more extensive research
than what we've heard so far, this is Ian Hickson's mailing list and as
I recall, he puts great emphasis on research and the proceedings being
1 - 100 of 160 matches
Mail list logo
