[whatwg] Script-related feedback

[Ian Hickson]

On Wed, 28 Nov 2012, Kyle Simpson wrote:
> > 
> > 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.

My assertion above is that parsing the script *can be* done *async*. I'm 
not saying it *is*, that's an implementation detail. I'm also not saying 
it has to be done off the main thread; you can do things in non-blocking 
fashions with just one thread -- e.g. with cooperative multitasking, the 
compiler yielding to the event loop at regular intervals, very much like 
how HTML has been parsed for years.


> That makes the giant (and I think faulty) assumption that the device in 
> question has enough spare resources to give multiple threads

Not at all. You don't have to use threads to do things async.

But having said that, devices these days are more than capable of 
compiling JavaScript async without noticeable performance degradation. You 
could do it on old 286s 15 years ago, you can definitely do it on 
quad-core ARM phones today.


> There have been a number of articles referencing issues where complex 
> scripts do in fact take a non-trivial amount of parsing time on limited 
> mobile devices. Even if such work wasn't strictly blocking the main UI 
> thread, the fact that it may take a lot of processing (or memory) power 
> from the device might very well mean that large parsing tasks could 
> starve necessary resources, so even if it's on another thread, there's 
> still very much not a "non-issue" to consider.

The cost of fetching the file (in terms of battery for the radio, for 
example), is high too, in these scenarios. If you can afford to download 
the file, compiling it isn't going to be an issue.


> Moreover, as has been mentioned many times in various threads (and you 
> seem to gloss over repeatedly), the gmail mobile team passed down large 
> amounts of javascript "hidden" in a javascript /* … */ comment, so as to 
> prevent that large amount of code from being parsed, until "later" when 
> the hit was acceptable, because they felt that the parsing and/or 
> execution was non-trivial enough to unacceptably slow down their app's 
> startup time.

That's understandable, since as far as I can tell, browsers don't actually 
yet compile code off the main thread. They also don't support any other 
new features we might add yet. My point is just that we don't have to add 
a new feature, because browsers haven't yet done what can already be done.


On Wed, 28 Nov 2012, Kyle Simpson wrote:
> 
> You ask us not to make duplicate arguments because you say that it just 
> clogs up this list and does nothing to change the outcome of your 
> decision. I would like to ask that you not do the same.

I've committed to responding to all the feedback sent to the list. If 
people make duplicate arguments, I can either ignore them, or respond to 
them; if I respond to them, I'm naturally going to respond in the same way 
as I did before. To do otherwise would be to encourage people to just keep 
making the same arguments in the hope that I'd just randomly change my 
mind. :-)

(This is not a symmetric situation; editors don't send feedback on this 
list, they respond to feedback, whereas everyone else sends feedback.)


> What it boils down to is, you feel that the onus is on the developers of 
> the scripts themselves to change so they are more "performance 
> optimization friendly" for those who use the scripts.
> 
> There are a number of us who work in the performance optimization 
> consulting arena, and when we consult with a site who's using a bunch of 
> third party scripts, and most of those scripts are not written the way 
> you think they should be, those clients aren't happy when we have to 
> tell them "sorry, your only option to optimize the performance is to 
> make your own modifications to those 3rd party scripts, and then 
> self-host them, and then keep up with merging changes constantly, etc…" 
> or some other such impractical nonsense.

Clearly the up-stream providers are those who should support these 
mechanisms, not the library users.


> Perhaps you want to drag this issue out long enough (been under 
> discussion for almost 2 years now) that all those poorly designed 
> scripts across the web are just eventually made obsolete or finally 
> "fixed" without the web platform needing to address it. The rest of us, 
> I think, would like to actually make performance gains and optimizations 
> now. It will be years and years before most of the popular scripts on 
> the web may be rewritten in the way you suggest. It's just a shame that 
> performance has to continue to suffer until then.

Why would it take longer for script authors to fix their libraries than 
for browser vendors to fix their browsers? Nothing is stopping browsers 
from implementing off-main-thread script parsing right now, but they 
haven't done it yet, as far as I can tell.


On Mon, 17 Dec 2012, Andy Davies wrote:
> 
> OK, so we have async and defer which will still block DOMContentLoaded 
> and to defer anything until after DOMContentLoaded developers have to 
> resort to JavaScript.

Why do you want to defer things until after DOMContentLoaded?


> Sites that want to implement CSP are going to lose the JS to load JS 
> route unless they allow inline scripts which probably defeats one of the 
> reasons they want to use CSP in the first place.
> 
> What we need are better ways of hinting to the browser what the priority 
> of the external JS is i.e. the current default behaviour, async, and 
> defer behaviours with options to defer until after DOMContentLoaded or 
> onload.
> 
> Users shouldn't have to wait for Facebook, Google Plus, Twitter or A N 
> Other 3rd party script to execute before they can start interacting with 
> a page and we need to make it easy for developers to implement these 
> scripts.

Why can't users interact with the page before DOMContentLoaded?


On Thu, 29 Nov 2012, Simon Pieters wrote:
> On Thu, 29 Nov 2012 04:35:21 +0100, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > Having the exception object, if any, in the onerror callback, seems 
> > reasonable, and would indeed limit how many more arguments we may have 
> > to add over the years. It seems that providing it as an argument would 
> > be better than as a global, though.
> 
> One question is what should happen with exceptions that propagate 
> upwards in the case of dedicated workers. Should a new exception object 
> be created for each worker up the chain, and finally for window? 
> ErrorEvent would also need a new member for this.

I'm not really sure how we could create new exception objects in this way. 
Anything can be thrown as an exception object, as far as I can tell.

(Regarding the original issue: it's blocked awaiting implementation 
commitments, as mentioned in my last e-mail on this topic.)


On Mon, 3 Dec 2012, Adam Barth wrote:
> 
> Currently, there are a number of ways to load a script from the network 
> and execute it, but none of them will actually load and execute the 
> script as fast as physically possible.  Consider the following markup:
> 
> <script async src="path/to/script.js"></script>
> 
> In this case, the user agent will wait until it receives the last byte 
> of script.js from the network before executing the first byte of 
> script.js.

It had better, since JavaScript requires that syntax errors in the lasy 
byte prevent execution of the first byte.


> The main ingredient that we're missing is a way for the author to signal 
> to the user agent which chunks of scripts are safe to execute in 
> parallel with loading subsequent chunks from the network. Fortunately, 
> the web platform already has a mechanism for breaking a single HTTP 
> response body into chunks that are processed sequentially: 
> multipart/mixed.
> 
> For example, if an HTTP server provides a multipart/mixed response to a 
> request for an image, the <img> element will display each part of the 
> response in sequence, animating the image.  Similarly, if an HTTP server 
> provides a multipart/mixed response to a request for an HTML document, 
> the user agent will display each part of the response sequentially.
> 
> One way to address this use case is to add multipart/mixed support to 
> the <script> element.  Upon receiving a multipart/mixed response to a 
> request for a script, the <script> element must execute each part of the 
> response as they become available.  This behavior appears to be 
> consistent with the definition of multipart/mixed 
> <http://tools.ietf.org/html/rfc2046#section-5.1.3>.
> 
> 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 a 
> multipart/mixed response.

This seems like an overly complicated way of solving this problem.

Why not just introduce a keyword or pragma to JavaScript that tells the 
user agent to act as if the end of the Program production had been 
reached, and that it should treat the remainder of the file as another 
Program?

This could even be done in a backwards-compatible fashion by having the 
syntax to do this be something that down-level clients ignore, e.g.:

   /*@BREAK*/

...or some such.


On Mon, 3 Dec 2012, Ojan Vafai wrote:
> 
> Someone pointed out a use-case to me: a progress bar showing how far 
> along the page load is. You could do this without an event by just 
> putting the appropriate bit in each chunk of the script, but you 
> couldn't do this if you use "defer" instead "async" (i.e. you want a 
> progress bar, but you don't want the script to execute).

If we want to support this, we could just make progress events fire at 
<script> elements. People have already asked for them to fire at <img> 
elements for similar reasons.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'