- From: Glenn Maynard <glenn@zewt.org>
- Date: Thu, 26 May 2011 13:33:43 -0400
On Thu, May 26, 2011 at 11:56 AM, Nicholas Zakas <nzakas at yahoo-inc.com> wrote: > I'm a little surprised that this conversation has swooped back around to performance and whether or not there's a valid use case here. Stopping and reevaluating periodically is a good idea, when proposing added complexity to the platform. > Moving parts of the JavaScript download/execution process doesn't allow me to control when that script will be executed, which as I mentioned in a previous email, is really the crux of the issue. The crux of the issue, according to your previous mail, was that executing the top-level of a script has to take a nontrivial amount of time, which is why you want to control when it happens. Based on both benchmarking and logical examination of what's happening, that doesn't seem to be the case: executing the top-level of a function, when using the loader-function paradigm, takes no significant time at all. Can you reply to my mail, and explain why the loader-function paradigm doesn't work for you? Maybe we discussed it before, but I'm having trouble thinking of any problems with it. > 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? You have effectively the same thing with a loader function; it just takes marginally more cooperation from the resource itself (wrapping it inside a function), which I think is fine. -- Glenn Maynard
Received on Thursday, 26 May 2011 10:33:43 UTC