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 you could already do this: 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. You have said this same thing no less than 10 times across various threads and communications. I really don't think anyone who's following this particular issue is unclear about your stance. ------- 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. Your approach is like tail-wagging-the-dog: let's make sure performance stays less than optimal, so that eventually the designers of these scripts have to wake up and fix it. 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. Giving us a mechanism by which we could load existing scripts written and maintained by others, which we don't control, in a way that is more performant than what we can currently do, regardless of how that script is designed to self-execute or not, would be a very useful tool to us, despite you insisting it's not useful. Also, some scripts, by nature of what they do or how they do it, will ALWAYS have to auto-execute. Consider the feature-tests that jQuery or Modernizr do automatically during their initialization. I think it would hurt both jQuery and Modernizr and others like them if users all of a sudden had to start calling a $.init() or something like that before they could use the script. The untold tens of thousands of sites and books which explain how to use these scripts would all be rendered completely inaccurate if such a major paradigm shift were to happen. --Kyle
