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 ha
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
Adam-
> To load and execute a script as quickly as possible, the author would
> use the following markup:
>
>
>
> 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 a multipart/mixed response.
I lik
> >> 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 yo
>> 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
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 tha
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 as
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
automatic
> 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 use
> 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 th
>> 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
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
> manag
>> 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.
Wel
> 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 t
> 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 (
> **
> Summary:
>
> 1. `preload` attribute on
> 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
> 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 scr
I'm still going to respond, in detail, with code comparisons, to Jake's
suggestions that the other proposals besides mine handle all my stated
use-cases.
However, before I do that, just to document for posterity, I just recalled
another use-case which is a feature very frequently requested of L
> How is this any different from the case today when
> 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 thin
> (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, `
> 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
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 use-c
> Do you have a link to your preload proposal?
My main `` proposal (skip the first section of this LONG email,
proposal starts at "Summary:" several paragraphs down):
http://lists.whatwg.org/htdig
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 old-sc
> 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 th
> 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, th
> This, along with Ilya's proposed (
> 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 everything we need f
>> 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
I'd also like to make the observation that putting .loaded()
together with
>> 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=fa
>> 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
?> 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: