? The ability to separate download and execution is a trend that has not
only emerged, but continues to be explored. There are problems with the
previous solutions, the biggest of which (in the case of #1 and #2) is the
reliance on the browser caching behavior which may, in some instances, lead
? The major issue I have with the way the spec is written is that there is
no way to feature detect this capability. I'd like this behavior (which I
agree, is useful), to be more explicit so we can easily make use where
available.
I agree, the spec doesn't make it clear in its current wording
? One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be used in markup. I.e. you can do
things like:
html
head
script src=a.js noexecute onload=...
script src=b.js noexecute onload=...
script src=c.js noexecute onload=...
/head
Doesn't link
?
I'm not sure why you are narrowing the scope to script loaders? (I
imagine you're referring to js-libraries which help with loading
scripts faster?)
Yes, script loaders like LABjs are the primary use-case that I'm concerned
about in terms of giving the load-but-defer-execution behavior to.
?
I don't think readyState as Kyle describes is an appropriate candidate
mechanism because it's not an actual indicator that the functionality
exists. The only thing you can really be sure of if readyState is
uninitialized is that the script element supports readyState. The fact
the only
? I think we should do the readyState thing and put a note in the spec
saying that implementors should be polite to authors and not implement the
readyState property until they also implement the behavior that setting .src
on a not-in-tree node starts the HTTP fetch (in order to make the
? Is there a specific problem with letting Web Workers handle this use
case?
They should not interfere with the UI thread.
I think the primary reason why Web Workers is not useful is that it's not
widespread enough adoption yet to be useful to the script loader community.
? Isn't this just a quality of implementation issue?
No, frankly it isn't. No matter how good the implementation of the
JavaScript engine on mobile, the mobile device will always be much more
limited in processing power than a desktop browser environment. There are
those who think that the
Can you list some of them? Most of the ones I can think of are ultimately
different forms of the same optimization.
I would first refer you to the use-cases that Steve Souders has documented
around his ControlJS library. His commentary on this topic is far more
comprehensive than anything I
? If that's what you were responding to, then I think your response is
simply incorrect. There's nothing whatsoever that requires that a web
browser freeze up its UI while parsing a script. If it does so, it's a
quality of implementation issue, pure and simple.
You don't need to be more
?
Mighty conjecture, chap. Multithreading is even possible on
microcontrollers like the Atmel ATmega32 ? so why should a modern
operating system running on reasonable hardware not be able to do it?
In most mobile devices I've had the exposure to developing for,
multi-threading is not
? Regardless, considering such things is way outside the scope of anything
that's going to be useful for web developers in the near-term dealing
with these use-cases.
Yes, but so is the proposal here, no?
No, I don't think so. A huge part of my point with the proposal is that it
builds on
?
You're also ignoring the fact that there are several other documented
use-cases for execution-deferral that are not related to mobile (or
multi-threading) at all. That maybe the 80% use-case for this proposal,
but it's certainly not the only reason we want and need a feature like
this.
Could
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
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
The proposal is an optimization of these crude hacks. Authors using such
hacks are unlikely to stop using them because the optimization does not
work on deployed clients.
What will happen is that people using the proposed feature will intro-
duce subtle bugs in their code (like calling
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
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
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
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
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
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
(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.
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
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
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
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
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
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
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` property. To execute the script, you add the script element to
the DOM. To
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
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 executed when the fetch completes; call
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
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
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,
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
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.)
[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
Since nobody seems to object, I'm going to revert r6543 and make
onreadystatechange special.
Since nobody seems to object? You had this thread active with this
suggestion for less than a day, and that's long enough to conclude that
noone objects? Man, am I sorry I was away from my email
In regards to all the concern about double-firing of load detection logic,
IE9 added both `onload` event firing to their existing script element's
`onreadystatechange` firing. That's been around now for 6 months (not to
mention the year long platform-preview stage where content was tested in
So, can I clarify something? You have moved `onreadystatechange` and
`readyState` off of the script element entirely, and onto the HTML
element?
No. They've been removed from elements (and windows) entirely. They
remain on Document.
So, if I understand correctly, you've simply said there
Ian,
The cost of parsing the script can be done async, even off the main thread
in theory, so it's a non-issue.
You have asserted many times that parsing is off the main thread, therefore it
doesn't matter. That makes the giant (and I think faulty) assumption that the
device in question has
Ian,
The only cost there could be is the cost
of executing the script, and it's already trivial to offload that: just
put all the code in a function, then call the function when you're ready.
It's already possible now to design scripts such that they don't run until
you call them, so you
Adam-
To load and execute a script as quickly as possible, the author would
use the following markup:
script async src=path/to/script.js/script
The HTTP server would then break script.js into chunks that are safe
to execute sequentially and provide each chunk as a separate MIME part
in
I like the spirit of this idea, but one concern I have is about the script
load and readystate events. It seems that authors will want to know when
each chunk has finished executing (in the same way they want to know that
scripts themselves finish).
Why? What would you do in such an
One suggestion is to added a state to the readyState mechanism like
chunkReady, where the event fires and includes in its event object
properties the numeric index, the //@sourceURL, the separator identifier, or
otherwise some sort of identifier for which the author can tell which chunk
Further evidence that the current state of the web is not friendly with respect
to how browsers default to treating script loading/parsing/executing.
https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-javascript-sdk-truly-asynchronous-loading/10151176218703920
The efforts
Increasingly, sites are doing client-side rendering at page load time, which is
breaking the (useful) functionality of being able to have a #hash on a URL that
auto-scrolls the page to make some element visible after page-load.
A perfect example of this problem is that most #hash URLs (as far
I'm proposing a couple of companion APIs to the already standardized
`requestAnimationFrame(..)` API.
First: https://gist.github.com/getify/5130304
`requestEachAnimationFrame(..)` and `cancelEachAnimationFrame(..)`
This is the analog to `setInterval(..)`, in that it runs the handler
when should autoscroll be called? only after a url with a hash is clicked in
the same page? when following a link to a : url#specific_hash? both cases?
I initially conceived it as only firing on initial page load for a URL#hash, so
definitely that case. But I can also see how it might be
So, to that end, what about just adjusting the spec for the hashchange
event to also fire when the page is initially loaded if the URL contains a
fragment identifier (hash)? The other scenarios mentioned would already be
covered by the hashchange event.
I think there's one critical thing
There have been times this automatic behavior has been quite annoying
because of accidential ID/hash overlap.
Please explain how a document subresource can be “accidentally”
referred to by a URL be “accidental”. I do not understand it.
In my case, I ran across this once (not too long ago)
This is a long and complicated topic with lots of history. Please bear with
the length of my reply.
It seems that people want something that:
- Lets them download scripts but not execute them until needed.
- Lets them have multiple interdependent scripts and have the browser
manage
But I'd settle for anything, no matter how complex, as long as it actually
solves the many use cases. Your proposed option has potential, as long as
the missing event part is addressed.
It seems to me that from an IE-perspective, the only missing piece is the
event itself.
Well,
I have been wrestling pretty hard with script loading issues lately. I'd
say that having the browser manage script interdependency is probably a
bad and cumbersome way to solve these issues.
What do you mean by having the browser manage script interdependency? As far
as I am aware, this
The IE4-10 technique is invisible to pre-parsers, if we're chasing
performance here it's not good enough.
...
Also invisible to preloaders.
I personally don't care about scripts being discoverable by pre-parsers. I have
done testing and am not convinced that something appearing earlier (in
**
Summary:
1. `preload` attribute on script tags in markup, `preload` property on
script elements created by code. In either case, its presence tells the
browser not to execute the script once it finishes loading.
2. `onpreload` event fired on any script
Which of your use-cases have not been met? So far I've seen only I want X,
Y, Z but not what you need X, Y, Z to achieve that isn't covered by other
simpler proposals or existing features.
You know, I keep relying on the fact that the body of work on this topic for
almost 3 years ought NOT
Pre-parsers can kick in before a page is actually opened, but script cannot
be executed. Let me dig up some numbers on the benefits of this report
back. But logically, [parse html]-[load script] is always going to be faster
than [parse html]-[parse inline script]-[execute inline
How is this any different from the case today when script elements are
fetched and run in the situation where one 404's?
Right now, without any script loader, AFAICT, if A loads fine, B 404's or
500's, and C loads fine, both A and C will run, and usually C will have lots of
cascading errors
I am interested to see how the above use-cases would be met in your
counter proposal(s) to see if it would be simpler/faster. If LabJS is
a requirement, it must be factored in as a unit of complexity and
load-step.
Please do this rather than declare anything to be insufficient without
Ok, and I'm saying they shouldn't be asking LABjs to handle it, they should
be asking the devtools teams at browser vendors to give them ways to deal
with it. You're not going to be able to pause execution for code, implement
future breakpoints, or debug root causes for this sort of thing
(AT EYE-WATERING-LENGTH)
I'm sorry I'm too verbose on the list for everyone's taste. Every time I'm
brief and make assumptions, I get accusations like Jake's repeated ones that
I'm just asserting without reason.
FWIW, my exhaustion of this process is not about my eyes, but my fingers sure
(being as brief as I possibly can...)
As per the existing outline, I don't see how it could have any sensitivity.
So, just to clarify, `script dependencies=…` waiting on some other script
tag is ONLY waiting on that script tag loading to have some sort of positive
network result, whether
So maybe a concept of optional dependency would be useful?
1. not all dependencies are JS files, e.g. authors use plugins to load
template files, JSON, images, etc.
2. not all dependencies are usefully satisfied immediately after their JS
file is loaded, e.g. some libraries may need
About a week ago, I presented a set of code comparing the script
dependencies=.. approach to the script preload approach, as far as creating
generalized script loaders.
There were a number of concerns presented in those code snippets, and the
surrounding discussions. I asked for input on the
FWIW, I'd be much more in favor of Jonas' proposal, at this point, than the
dependencies=.. proposal. The `noexecute/execute()` is conceptually pretty
similar to the preload proposal I've been pushing. As far as I can tell from
how Jonas describes it, it looks like it would fit most of the
Do you have a link to your preload proposal?
My main `script preload` proposal (skip the first section of this LONG email,
proposal starts at Summary: several paragraphs down):
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/039973.html
Then proposal slightly amended here:
I have put together a simple soft proposal for a pair of HTTP Request/Response
headers that bridge to the browser's sessionStorage mechanism for session ID
storage. It's basically to embrace the new SPA style architecture prevalent on
the web, and the use of sessionStorage, instead of the
Why not just use cookies ? I feel they're sufficient to do what you need.
Asked differently: in what way are cookies insufficient so that we need a new
different API/feature?
There are substantive differences between the behavior of session cookies vs.
sessionStorage. Without re-arguing the
On Thu, 31 Oct 2013, Kyle Simpson wrote:
Session cookies are preserved at the browser-level, which means they are
kept around for the lifetime of the browser instance. sessionStorage,
OTOH, is kept only for the lifetime of the tab. In many respects, this
makes sessionStorage more
This, along with Ilya's proposed link rel=preload (
https://docs.google.com/a/google.com/document/d/1HeTVglnZHD_mGSaID1gUZPqLAa1lXWObV-Zkx6q_HF4/edit#heading=h.x6lyw2ttub69),
and JavaScript modules (
https://github.com/dherman/web-modules/blob/master/module-tag/explainer.md)
gives us
So, if that's how we think this would work, we need to understand how the
`execScript(..)` logic is going to be treated. Is creating a script
element dynamically and inserting it going to make sure that it either:
a. executes sync
b. executes async, but a.js will *definitely* execute
I'd also like to make the observation that putting link rel=preload.loaded()
together with script.loaded(), and indeed needing a promise mechanism to wire
it altogether, is a fair bit more complicated than the initial proposals for
script preloading use-cases from the earlier threads over the
As I noted above, what we need to know (and I guess we need to know this
from all browsers) if there's a *guarantee* of a-b-c execution order (even
if all 3 are executing async)
I don't believe there is such a guarantee, unless the spec spells it out
explicitly.
The `async=false` stuff
I'd say the first syntax is a bit verbose for what I was dreaming 4 years
ago when I started asking for a simple script preloading mechanism, but
it's just this side of acceptable. If we have to take the second approach,
I say that's unacceptably more verbose/complex and falls short of my
Surely our goal should be to make script loaders unnecessary.
There's unquestionably a lot of folks on this thread for whom that is their
main concern. I think it's a mistake to assume that because they mostly seem to
be working as browser developers (which strongly influences their
There are features being added to the DOM/web platform, or at least under
consideration, that do not have reasonable feature tests obvious/practical in
their design. I consider this a problem, because all features which authors
(especially those of libraries, like me) rely on should be able to
A lot of the untestable bugs have been around for a really, really long time,
and are probably never going away. In fact, as we all know, as soon as a bug is
around long enough and in enough browsers and enough people are working around
that bug, it becomes a permanent feature of the web.
So
84 matches
Mail list logo
