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
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
On 2/10/11 5:09 PM, Bjoern Hoehrmann wrote:
And constructing whatever output model (AST, bytecode, whatever) your
parser produces.
I can grant you persisting information about the structure to some point
but generating byte code is not the job of the parser
Well, the parser has to output
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 is never executed, so window.x is never
defined.
oops, right, but i don't know that that complicates things much. you
On Wed, Feb 9, 2011 at 9:46 AM, Glenn Maynard gl...@zewt.org wrote:
- The scripts in comments hack would be unneeded. That's an unpleasant
hack, because it will both prevent browsers from caching compiled scripts,
and prevent scripts from being compiled in the background. Specifying a
bogus
On Wed, Feb 9, 2011 at 12:08 PM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
Another approach:
The link tag is meant to support a prefetch value for the rel attribute
asking to preemptively cache the resource:
- http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-prefetch
-
i'm not sure you need an execute(), you might benefit from an event
listener to tell you if a resource has been prefetched. but this
general path seems less icky to me than most if not all of the other
paths suggested in this thread.
you will surely take benefit from the onload event
On Wed, Feb 9, 2011 at 12:08 PM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
Another approach:
The link tag is meant to support a prefetch value for the rel
attribute
asking to preemptively cache the resource:
- http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-prefetch
On Wed, Feb 9, 2011 at 2:46 AM, Glenn Maynard gl...@zewt.org wrote:
- Just for comparison: script src=path.js noexecute
onload=this.execute() seems roughly equivalent to script async, and
like async, falls back on immediate loading if noexecute isn't supported.
script defer could be
On 2/9/11 12:27 AM, Kyle Simpson wrote:
I can't speak definitively as to how the JavaScript engine is
implemented (and if the code is significantly different between mobile
and desktop).
In Gecko's case, it's identical (modulo the different JIT backends for
ARM and x86 and x86-64, of course).
On 2/9/11 2:19 AM, John Tamplin wrote:
I am not sure I understand why you are so opposed to providing a
mechanism for an application to tell the browser it would like the
parsing to not necessarily be performed immediately on a downloaded script.
I'm not opposed to that, as should be clear if
?
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
...@lists.whatwg.org]
On Behalf Of Glenn Maynard
Sent: Wednesday, February 09, 2011 6:15 AM
To: timeless
Cc: Alexandre Morgaut; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Wed, Feb 9, 2011 at 12:08 PM, Alexandre Morgaut
alexandre.morg
On 2/9/11 10:37 AM, Kyle Simpson wrote:
I think you're assuming a uniformity to browser implementations that's
simply not there.
No, I'm relying on the growing trend of more and more web authors being:
1) aware of performance issues, especially initial page-load performance
2) able to use more
What we're suggesting is that we be able to directly
control execution, and in so doing, make an indirect hint to the browser
that it should also strongly consider deferring the parsing.
That sounds fine to me.
Sorry for the confusion, that's exactly what I had in mind with the proposal
The link tag is meant to support a prefetch value for the rel
attribute asking to preemptively cache the resource:
- http://blog.whatwg.org/the-road-to-html-5-link-relations#rel-prefetch
- http://davidwalsh.name/html5-prefetch
For link rel=prefetch to address the use-case, some event
On Wed, Feb 9, 2011 at 6:57 PM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
On Feb 9, 2011, at 4:40 PM, Nicholas Zakas wrote:
I had chatted with a few folks about using rel=prefetch, but there seems to
be a lot of issues that would have to be resolved to get the behavior I'm
after.
] Proposal for separating script downloads and execution
On Wed, Feb 9, 2011 at 6:57 PM, Alexandre Morgaut
alexandre.morg...@4d.com wrote:
On Feb 9, 2011, at 4:40 PM, Nicholas Zakas wrote:
I had chatted with a few folks about using rel=prefetch, but there seems to
be a lot of issues
On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson get...@gmail.com wrote:
The original proposal is in fact more focused on the markup-driven use-case
than on the script-driven use-case. The original proposer, Nicholas, agreed
in an earlier message that he's really more concerned with script-driven
?
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
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com wrote:
? 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
On Tue, 08 Feb 2011 10:28:15 +0100, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com wrote:
? One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be
On Tue, Feb 8, 2011 at 1:28 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com wrote:
? One reason I like the noexecute proposal more than relying on
readyState is that noexecute can be used in
Jonas Sicking wrote:
On Tue, Feb 8, 2011 at 1:28 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com
wrote:
? One reason I like the noexecute proposal more than relying on
readyState is
On Tue, Feb 8, 2011 at 10:44 AM, Henri Sivonen hsivo...@iki.fi wrote:
I thought the case being addressed here is fetching scripts early but not
compiling or evaluating them until the app knows the functionality provided
the script is going to be needed. The degradation story depends on the
On Tue, 08 Feb 2011 17:06:52 +0100, John Tamplin j...@google.com wrote:
I am not on the GMail team, but we did see similar issues on the GWT
team -- simply parsing the downloaded script takes a lot of time and
interferes with user interaction with the UI, so as awkward as it seems,
On Tue, Feb 8, 2011 at 11:10 AM, Anne van Kesteren ann...@opera.com wrote:
Is there a specific problem with letting Web Workers handle this use case?
They should not interfere with the UI thread.
I'm not really the one to answer and I don't know the details of the problem
or solution, I was
On Tue, 08 Feb 2011 17:21:31 +0100, John Tamplin j...@google.com wrote:
I'm not really the one to answer and I don't know the details of the
problem
or solution, I was just trying to give some background to why it was done
the way it was given the comment from Henri.
Also, I thought Web
On Tue, Feb 8, 2011 at 11:35 AM, Anne van Kesteren ann...@opera.com wrote:
They have a way to download and execute scripts. So if the UI thread has a
minimal script that takes care of creation of workers and creates a tunnel
for DOM modifications you could theoretically be all set. (I have not
? 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
...@whatwg.org; Steve Souders; Tony Gentilcore
Subject: Re: [whatwg] Proposal for separating script downloads and execution
Jonas Sicking wrote:
On Tue, Feb 8, 2011 at 1:28 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 4, 2011, at 03:13, Jonas Sicking wrote:
On Thu, Feb 3, 2011 at 4:45 PM, Kyle
Of John Tamplin
Sent: Tuesday, February 08, 2011 11:57 AM
To: Anne van Kesteren
Cc: Steve Souders; Jonas Sicking; wha...@whatwg.org; Henri Sivonen; Nicholas
Zakas; Tony Gentilcore
Subject: Re: [whatwg] Proposal for separating script downloads and execution
On Tue, Feb 8, 2011 at 11:35 AM, Anne van
? 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.
On 2/8/11 3:56 PM, Kyle Simpson wrote:
Yes, it's important to note that it's not even the *execution* of
JavaScript code that's actually the particular issue, but rather just
the parsing of it (even if invoking of the functionality is deferred
until later) that causes the biggest slowdown, in
On 2/8/11 4:13 PM, Boris Zbarsky wrote:
On 2/8/11 3:56 PM, Kyle Simpson wrote:
Yes, it's important to note that it's not even the *execution* of
JavaScript code that's actually the particular issue, but rather just
the parsing of it (even if invoking of the functionality is deferred
until
On Tue, Feb 8, 2011 at 4:13 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Here's the thing. Parsing is a black-box behavior. Nothing says a browser
needs to do it right before execution, that it needs to happen on the main
thread, or that it's happening at all.
For example, for Gecko we have
On 2/8/11 4:21 PM, John Tamplin wrote:
I think it is useful to provide ignorable hints to browser to indicate
that you want this downloaded but you don't need it parsed right away.
Yes, that's fine. As long as we're not adding some sort of new hard
requirements on actual behavior here, all's
On Tue, 08 Feb 2011 16:06:52 -, John Tamplin j...@google.com wrote:
I am not on the GMail team, but we did see similar issues on the GWT
team --
simply parsing the downloaded script takes a lot of time and interferes
with user interaction with the UI, so as awkward as it seems,
? 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
On Tue, Feb 8, 2011 at 7:31 PM, Kyle Simpson get...@gmail.com wrote:
It's also tempting to just get mired down in this one use-case of mobile
JavaScript parsing deferral. While this use-case is a great example of why
controlling execution is important, there are plenty of other use-cases for
On 2/8/11 7:31 PM, Kyle Simpson wrote:
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.
That's not what the question was about.
It's also
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
On 2/8/11 11:04 PM, Kyle Simpson wrote:
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.
That's not what the question was about.
The
? 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
Kyle Simpson get...@gmail.com schrieb am Tue, 8 Feb 2011 23:27:35
-0600:
I can't speak definitively as to how the JavaScript engine is
implemented (and if the code is significantly different between
mobile and desktop). But I can say that even if their code is
substantially the same, I could
On Tue, Feb 8, 2011 at 11:26 PM, Boris Zbarsky bzbar...@mit.edu wrote:
You don't need to be more efficient to avoid freezing the UI. You just
have to not do the parsing work in a single shot on the main thread. You can
either break it up (cooperative multitasking, effectively), or put it on a
I'm losing track in the noise of what the fundamental disagreements are--if
there even are any. I think the original proposal is a very good place to
start:
- Add a noexecute attribute to SCRIPT, which instructs the browser to
retrieve the script without executing it. noexecute implies async.
-
@lists.whatwg.org; Kyle Simpson
Subject: Re: [whatwg] Proposal for separating script downloads and execution
Doesn't link rel=prefetch mostly address the use-case of
load-but-don't-execute in markup? The reason script-inserted script elements
need this capability is more advanced than any use-case
On Tue, Feb 1, 2011 at 11:06 AM, Kyle Simpson get...@gmail.com wrote:
? 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
This behavior is important to the next generation of web apps,
especially for mobile.
- download the bytes of JS now
- execute later when specified (eg, when the user initiates a feature)
I've talked to several development teams that have already deployed this
functionality but it is
? 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
: Re: [whatwg] Proposal for separating script downloads and execution
This behavior is important to the next generation of web apps,
especially for mobile.
- download the bytes of JS now
- execute later when specified (eg, when the user initiates a feature)
I've talked to several
On Thu, Feb 3, 2011 at 4:45 PM, Kyle Simpson get...@gmail.com wrote:
? 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
On Thu, Feb 3, 2011 at 4:53 PM, Nicholas Zakas nza...@yahoo-inc.com wrote:
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
?
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.
Doesn't link rel=prefetch mostly address the use-case of
load-but-don't-execute in markup? The reason script-inserted script elements
need this capability is more advanced than any use-case for why you'd do so
in markup. In other words, I can't imagine that a script loader would rely
on
?
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
Problem Statement:
Loading JavaScript onto a page poses several performance issues. With a regular
script tag, the UA waits for download and then waits for execution. The defer
attribute helps by not blocking on download and deferring execution until later
but preserves execution order; the
? 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
, February 01, 2011 10:25 AM
To: whatwg@lists.whatwg.org
Cc: Nicholas Zakas
Subject: Re: [whatwg] Proposal for separating script downloads and execution
? The ability to separate download and execution is a trend that has not
only emerged, but continues to be explored. There are problems
? 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
101 - 162 of 162 matches
Mail list logo
