On 8/27/13 2:55 PM, Ian Hickson i...@hixie.ch wrote:
First, let's get down to use cases. Kyle did a great job of describing
some key use cases:
On Wed, 10 Jul 2013, Kyle Simpson wrote:
[Use-case Q:] I am dynamically loading one of those social widgets
that,
upon load, automatically scans
On 31 August 2013 00:04, Ryosuke Niwa rn...@apple.com wrote:
It'll be much harder to implement a new dependency API that replies on CSS
selectors if we care about the performance at all.
Where does the performance issue come from? It would only need to be
resolved once on node creation or
On 9/3/13 2:27 PM, Ryosuke Niwa wrote:
From the fact selector matching is slow.
Hold on. Back up.
Selector matching can't be all that slow per se: browsers do it a
_lot_. Do you mean doing the equivalent of document.querySelectorAll
can be slow?
-Boris
Original proposal:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040664.html
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-August/040666.html
In order to address use cases incDependencies and decDependencies satisfied,
I'm going to add the following proposals:
I
On Sep 3, 2013, at 3:45 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 31 August 2013 00:04, Ryosuke Niwa rn...@apple.com wrote:
It'll be much harder to implement a new dependency API that replies on CSS
selectors if we care about the performance at all.
Where does the performance
Per IRC discussion, I misunderstood the timing at which these at which
dependencies are executed. Now I agree it's desirable to have two values for
when needed as proposed by Ian in the original e-mail.
For other people following this thread's sake, a.js will execute immediately as
soon as
Hello folks. Sorry for the late response to several comments in this
mega-thread, I've mostly been traveling/vacationing for the past 2 months.
A teammate asked me to look at this in case I had comments. I don't know
web dev issues very well, so I'm going to restrain myself from offering
many
On Tue, Aug 27, 2013 at 11:55 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 11 Jul 2013, Yoav Weiss wrote:
I've recently contemplated the slightly related issue of adding the
media attribute to script, for declarative loading of scripts that
are only relevant to some viewports [1] While
On Aug 30, 2013, at 9:08 AM, Yoav Weiss y...@yoav.ws wrote:
On Tue, Aug 27, 2013 at 11:55 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 11 Jul 2013, Yoav Weiss wrote:
I've recently contemplated the slightly related issue of adding the
media attribute to script, for declarative loading of
On 8/30/13, Ryosuke Niwa rn...@apple.com wrote:
On Aug 30, 2013, at 9:08 AM, Yoav Weiss y...@yoav.ws wrote:
On Tue, Aug 27, 2013 at 11:55 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 11 Jul 2013, Yoav Weiss wrote:
[...]
They are fairly common, especially for loading of mobile UI
On Aug 30, 2013, at 4:36 PM, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 8/30/13, Ryosuke Niwa rn...@apple.com wrote:
I don't think it'll be hard to add the media attribute on the script element
at least in WebKit.
It'll be much harder to implement a new dependency API that replies on
I don't like the name jit, because it already has a different meaning
when talking about scripting. If this was for CSS or WebVTT or something
else other than scripts, it wouldn't be as bad...
On Fri, Aug 30, 2013 at 7:22 PM, Ryosuke Niwa rn...@apple.com wrote:
I don't quite understand why we
On Aug 30, 2013, at 5:54 PM, Glenn Maynard gl...@zewt.org wrote:
I don't like the name jit, because it already has a different meaning when
talking about scripting. If this was for CSS or WebVTT or something else
other than scripts, it wouldn't be as bad...
On Fri, Aug 30, 2013 at 7:22
On Aug 29, 2013 1:21 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi Ryosuke,
Based on the feedback here, it doesn't sound like you are a huge fan
of the original proposal in this thread.
At this point, has any implementation come out in support of the
proposal in this thread as a preferred
When Kyle and I originally started pushing for a way to preload JavaScript
many moons ago, the intent was very simple: to allow the downloading of
JavaScript and execution of JavaScript to be separate. The idea being that
you should be able to preload scripts that you'll need later without
On 27 August 2013 22:55, Ian Hickson i...@hixie.ch wrote:
On Tue, 9 Jul 2013, Bruno Racineux wrote:
Why not simply load all such scripts early in the head with 'defer',
which preserves the dependency order as determined by your app. Using
'defer' in head scripts is actually a very good
On Aug 29, 2013, at 8:37 AM, Nicholas Zakas standa...@nczconsulting.com wrote:
When Kyle and I originally started pushing for a way to preload JavaScript
many moons ago, the intent was very simple: to allow the downloading of
JavaScript and execution of JavaScript to be separate. The idea
On Tue, Aug 27, 2013 at 4:55 PM, Ian Hickson i...@hixie.ch wrote:
IMHO, if you have to write a script to solve use cases like these, you
haven't really solved the use cases. It seems that the opportunity we have
here is to provide a feature or set of features that addresses these use
cases
On 8/29/13, Nicholas Zakas standa...@nczconsulting.com wrote:
When Kyle and I originally started pushing for a way to preload JavaScript
many moons ago, the intent was very simple: to allow the downloading of
JavaScript and execution of JavaScript to be separate. The idea being that
you should
On Jul 13, 2013, at 5:55 AM, Andy Davies dajdav...@gmail.com wrote:
On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote:
On browser preloading:
There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
PreloadScanner and responsive design for mobile. Responsive
Hi Ryosuke,
Based on the feedback here, it doesn't sound like you are a huge fan
of the original proposal in this thread.
At this point, has any implementation come out in support of the
proposal in this thread as a preferred solution over
noexecute/execute()?
The strongest support I've seen in
First, let's get down to use cases. Kyle did a great job of describing
some key use cases:
On Wed, 10 Jul 2013, Kyle Simpson wrote:
[Use-case Q:] I am dynamically loading one of those social widgets that,
upon load, automatically scans a page and renders social buttons. I need
to be able
On 18 July 2013 23:28, Kyle Simpson get...@gmail.com wrote:
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
On Tue, Jul 9, 2013 at 12:39 PM, Ian Hickson i...@hixie.ch wrote:
The proposals I've seen so far for extending the spec's script preloading
mechanisms fall into two categories:
- provide some more control over the mechanisms already there, e.g.
firing events at various times, adding
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
On Mon, Jul 22, 2013 at 2:35 PM, Kyle Simpson get...@gmail.com wrote:
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
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:
On Mon, Jul 22, 2013 at 4:01 PM, Kyle Simpson get...@gmail.com wrote:
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):
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
wha...@whatwg.org
Subject: Re: [whatwg] Script preloading
On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote:
On browser preloading:
There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
PreloadScanner and responsive design for mobile. Responsive designs
mostly
On Mon, Jul 15, 2013 at 9:42 AM, Bruno Racineux br...@hexanet.net wrote:
Taking about executing script as quickly as possible (threads from 1012
which I missed and tried to glanced through just get better educated about
previous conversations).
Wouldn't browsers be able to store
On 7/15/13 3:42 AM, Bruno Racineux wrote:
Wouldn't browsers be able to store pre-parsed/compiled' scripts in a
separate byte code cache,
You mean like https://bugzilla.mozilla.org/show_bug.cgi?id=679942 ?
There's some discussion in there about whether this is a worthwhile
optimization with
ES6 modules[1] have a script loader API[2].
That API is pretty powerful to the point it can emulate other script
loaders, load files that are not ES6 modules, and even load text files
that aren't JS (intended for compilation of coffeescript-like languages,
but could be abused for
On 7/15/13 6:12 AM, Yoav Weiss y...@yoav.ws wrote:
On Mon, Jul 15, 2013 at 9:42 AM, Bruno Racineux br...@hexanet.net wrote:
Taking about executing script as quickly as possible (threads from
1012
which I missed and tried to glanced through just get better educated
about
previous
It goes beyond frameworks if based on pure 'access frequency'.
For example, a site backend you use daily or you favorite web app would be
also benefit.
Including the G+, Twitter and Facebook site's scripts, Map APIs, Google
News, or whatever you access most frequently from your machine.
On 7/15/13 3:02 PM, Yoav Weiss y...@yoav.ws wrote:
It goes beyond frameworks if based on pure 'access frequency'.
For example, a site backend you use daily or you favorite web app would
be
also benefit.
Including the G+, Twitter and Facebook site's scripts, Map APIs, Google
News, or
On 7/15/13 7:28 PM, Bruno Racineux wrote:
The outline there suggest: - When compiling a lazy script with no inner
functions, do a table lookup for a script with the same source location
(filename, lineno, column, source begin/end
So just to be clear: that bug is talking about script in the
On Fri, 12 Jul 2013 21:20:57 +0100, Kyle Simpson get...@gmail.com wrote:
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 that be a 2xx, 3xx, 4xx, or
5xx, and it
On Tue, 09 Jul 2013 20:39:45 +0100, Ian Hickson i...@hixie.ch wrote:
Would something like this, based on proposals from a variety of people in
the past, work for your needs?
1. Add a dependencies attribute to script that can point to other
scripts to indicate that execution of this script
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
On 7/10/13, Jake Archibald jaffathec...@gmail.com wrote:
On 9 July 2013 22:31, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 7/9/13, Ian Hickson i...@hixie.ch wrote:script id=jquery
src=jquery.js async/script
script id=shims src=shims.js async/script
script dependencies=shims
On 7/13/13 5:55 AM, Andy Davies dajdav...@gmail.com wrote:
On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote:
On browser preloading:
There seems to an inherent conflict between 'indiscriminate'
Pre-parsers/
PreloadScanner and responsive design for mobile. Responsive designs
Nobody should be arguing about 'pet projects' or 'ignorance' here, it's
really uncalled for. Characterizing strong counter arguments or strong
views as 'attacks' is also unnecessary.
May I remind you Alex that this thread's request for feedback started with
two simple questions: Would something
On 12 July 2013 01:25, Bruno Racineux br...@hexanet.net wrote:
On browser preloading:
There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
PreloadScanner and responsive design for mobile. Responsive designs
mostly implies that everything needed for a full screen desktop
On 7/11/13 6:00 AM, Jake Archibald jaffathec...@gmail.com wrote:
link rel=subresource almost 50% of scripts sent without proper
caching headers. If the browser is doing what it should do, it won't
cache those
This is not how link[rel=subresource] should work, the first request
for the
On 9 July 2013 20:39, Ian Hickson i...@hixie.ch wrote:
A topic that regularly comes up is script loading.
I sent an e-mail responding to related feedback last year, though it
didn't get any replies to the script loading parts of it:
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
On Fri, Jul 12, 2013 at 4:31 PM, Kyle Simpson get...@gmail.com wrote:
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,
(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
On Fri, Jul 12, 2013 at 7:56 PM, Kyle Simpson get...@gmail.com wrote:
[ snip ]
Again: my question (which remains unanswered), the reason I stated the
error/retry/fallback use case in detail, is whether or not the dependency
attributes proposal, as put forth by Jake (and Ian) will or will
(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
On Wednesday, 10 July 2013, Kyle Simpson wrote:
You know, I keep relying on the fact that the body of work on this topic for
almost 3 years … I've spent more time over the last 4+ years obsessing on
script loading than any other developer … I am saying the same things I've
been saying for
On 10 July 2013 17:37, Jake Archibald jaffathec...@gmail.com wrote:
On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote:
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
markup) leads
Here's the Plus URL without the googler cruft:
https://plus.google.com/u/1/+IlyaGrigorik/posts/8AwRUE7wqAE
On Thu, Jul 11, 2013 at 3:47 PM, Jake Archibald jaffathec...@gmail.comwrote:
On 10 July 2013 17:37, Jake Archibald jaffathec...@gmail.com wrote:
On 10 July 2013 16:39, Kyle Simpson
On Thu, Jul 11, 2013 at 9:41 PM, Kyle Simpson get...@gmail.com wrote:
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
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
On browser preloading:
There seems to an inherent conflict between 'indiscriminate' Pre-parsers/
PreloadScanner and responsive design for mobile. Responsive designs
mostly implies that everything needed for a full screen desktop is
provided in markup to all devices.
Isn't the
On 9 July 2013 20:39, Ian Hickson i...@hixie.ch wrote:
1. Add a dependencies attribute to script that can point to other
scripts to indicate that execution of this script should be delayed
until all other scripts that are (a) earlier in the tree order and (b)
identified by this
On 9 July 2013 21:41, Kyle Simpson get...@gmail.com wrote:
http://wiki.whatwg.org/wiki/Script_Execution_Control
My proposal was to standardize what IE4-10 did, which is to start loading
a script even if it's not in the DOM, but not execute it until it's in the
DOM. Then, you monitor an event
On 9 July 2013 22:31, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 7/9/13, Ian Hickson i...@hixie.ch wrote:script id=jquery
src=jquery.js async/script
script id=shims src=shims.js async/script
script dependencies=shims jquery src=myscript.js
async/script
Why limit depends
On 7/9/13 7:09 PM, Kyle Simpson get...@gmail.com wrote:
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
On 10 July 2013 11:31, Bruno Racineux br...@hexanet.net wrote:
Anyway, as per your previous email I think we mostly agree that solution
#1 is not very practical (or infeasible per your word)
Given the suggestions I made to #1 in
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
On 10 July 2013 16:39, Kyle Simpson get...@gmail.com wrote:
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
On Wed, 10 Jul 2013 16:39:42 +0100, Kyle Simpson get...@gmail.com wrote:
I personally don't care about scripts being discoverable by pre-parsers.
[...]
For instance, I've added like link rel=prefetch annotations for my
scripts into the head of my document, and then done my normal
This is a good proposal and I'm hugely excited to see this getting more
attention! Thanks so much for bringing it up again.
There's one state that's not represented here which is download but do not
run, an inactive flag, if you will. I know this is important is some
situations where the overhead
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
I'm supportive of this proposal, and I think it'd help declarative script
loading.
I've recently contemplated the slightly related issue of adding the media
attribute to script, for declarative loading of scripts that are only
relevant to some viewports [1]
While it may complicate certain things
On 7/10/13 4:20 AM, Jake Archibald jaffathec...@gmail.com wrote:
On 10 July 2013 11:31, Bruno Racineux br...@hexanet.net wrote:
Anyway, as per your previous email I think we mostly agree that solution
#1 is not very practical (or infeasible per your word)
Given the suggestions I made to #1 in
A topic that regularly comes up is script loading.
I sent an e-mail responding to related feedback last year, though it
didn't get any replies to the script loading parts of it:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0221.html
It seems that people want something
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
On 7/9/13, Ian Hickson i...@hixie.ch wrote:
A topic that regularly comes up is script loading.
Yes, for years it has come up.
I jumped on the topic around 2009 here and on comp.lang.javascript to
add the idea about chain of responsibility to this solution.
The chain of responsibility pattern
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 just joined the list and glad this subject is brought up.
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. I'll try to explain,
talk about the defer
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
78 matches
Mail list logo
