Talk:Dynamic Script Execution Order - Revision history

Serverherder: /* response */

2011-01-03T15:05:46Z

response

← Older revision		Revision as of 15:05, 3 January 2011
Line 169:		Line 169:
	Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.		Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.

	~~<blockquote>~~

	<blockquote style="background-color:#ccc">		<blockquote style="background-color:#ccc">
Line 183:		Line 182:

	[[User:Getify\|Getify]] 00:50, 24 December 2010 (UTC)		[[User:Getify\|Getify]] 00:50, 24 December 2010 (UTC)

	</blockquote>		</blockquote>

	[[User:Getify\|Getify]] 21:39, 23 December 2010 (UTC)		[[User:Getify\|Getify]] 21:39, 23 December 2010 (UTC)

			<blockquote style="background-color: white">
			<p> A phased approach toward adopting this is reasonable and you clearly state the risks of both positions. My comments have derailed the true purpose of this discussion: ''Does the specification require modification''? Since the spec all ready provides a mechanism by which this functionality can be achieved, I believe it is best to reword the suggestion so it more appropriately conveys the importance of it, but don't think the behavior should be imposed on vendors.
			[[User:Serverherder\|Serverherder]]

Getify: /* response */

2010-12-24T00:50:45Z

response

← Older revision		Revision as of 00:50, 24 December 2010
Line 165:		Line 165:
	Script loaders can all ready choose ordered execution: chain the onload events. The issue is that vendors have chosen '''not''' to adopt the specification's suggestion. The high priority vendors place on performance suggests this was not done consciously. Instead of advocating WHATWG for additions to the spec, I think we may be better off advocating vendors implement the spec's suggestion. The existing implementation of parallelism for parser-inserted scripts suggests vendors would be willing to do so and the existing lack of support is merely an issue of communication.		Script loaders can all ready choose ordered execution: chain the onload events. The issue is that vendors have chosen '''not''' to adopt the specification's suggestion. The high priority vendors place on performance suggests this was not done consciously. Instead of advocating WHATWG for additions to the spec, I think we may be better off advocating vendors implement the spec's suggestion. The existing implementation of parallelism for parser-inserted scripts suggests vendors would be willing to do so and the existing lack of support is merely an issue of communication.

	At its core, the existing suggestion to retrieve upon src assignment is not altogether different than the eager-fetching performed for parser-inserted scripts. The risk still exists that the browser download a script that is never actually executed. For example, below a bunch of script tags, the HTML may contain a closing comment tag (-->) and one of the scripts doc.write("<!--"). Another risk is that the eager-fetching clog the fetch queue, delaying the download of any scripts included via document.write(). Vendors have '''chosen''' to assume this risk though, since its probability is low and the benefit high.		At its core, the existing suggestion to retrieve upon src assignment is not altogether different than the eager-fetching performed for parser-inserted scripts. The risk still exists that the browser download a script that is never actually executed. For example, below a bunch of script tags, the HTML may contain a closing comment tag (-->) and one of the scripts doc.write("<\!--"). Another risk is that the eager-fetching clog the fetch queue, delaying the download of any scripts included via document.write(). Vendors have '''chosen''' to assume this risk though, since its probability is low and the benefit high.

	Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.		Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.
Line 182:		Line 182:
	I understand your perspective, but I can say as the maintainer of a tool like LABjs that cares about keeping its relevancy for "survival", I won't take an action that I know is likely to cause a decline in the usefulness of my tool. Instead, I will take a more cautious, slow-to-change approach, while at the same time feature-testing for the new standards and using them if available. Only after a long time of the new feature-testable stuff being present will I consider removing the legacy stuff. This is a strategy I think almost every framework/lib maintainer would echo support for.		I understand your perspective, but I can say as the maintainer of a tool like LABjs that cares about keeping its relevancy for "survival", I won't take an action that I know is likely to cause a decline in the usefulness of my tool. Instead, I will take a more cautious, slow-to-change approach, while at the same time feature-testing for the new standards and using them if available. Only after a long time of the new feature-testable stuff being present will I consider removing the legacy stuff. This is a strategy I think almost every framework/lib maintainer would echo support for.

	~~~~~~~~		[[User:Getify\|Getify]] 00:50, 24 December 2010 (UTC)
	</blockquote>		</blockquote>

	[[User:Getify\|Getify]] 21:39, 23 December 2010 (UTC)		[[User:Getify\|Getify]] 21:39, 23 December 2010 (UTC)

Getify: /* response */

2010-12-24T00:50:04Z

response

@@ Line 169: / Line 169: @@
 Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images.  Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts.  Providing a means by which this decision can be circumvented undermines their choice.   I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.
-</blockquote>
+<blockquote>
 [[User:Getify|Getify]] 21:39, 23 December 2010 (UTC)

Serverherder: /* response */

2010-12-23T22:58:18Z

response

← Older revision		Revision as of 22:58, 23 December 2010
Line 161:		Line 161:

	The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.		The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.

			<blockquote style="background-color:#EEE">
			Script loaders can all ready choose ordered execution: chain the onload events. The issue is that vendors have chosen '''not''' to adopt the specification's suggestion. The high priority vendors place on performance suggests this was not done consciously. Instead of advocating WHATWG for additions to the spec, I think we may be better off advocating vendors implement the spec's suggestion. The existing implementation of parallelism for parser-inserted scripts suggests vendors would be willing to do so and the existing lack of support is merely an issue of communication.

			At its core, the existing suggestion to retrieve upon src assignment is not altogether different than the eager-fetching performed for parser-inserted scripts. The risk still exists that the browser download a script that is never actually executed. For example, below a bunch of script tags, the HTML may contain a closing comment tag (-->) and one of the scripts doc.write("<!--"). Another risk is that the eager-fetching clog the fetch queue, delaying the download of any scripts included via document.write(). Vendors have '''chosen''' to assume this risk though, since its probability is low and the benefit high.

			Likewise, vendors can calculate the risk/reward for script-inserted scripts and will likely make the same decision -- they implement this exact behavior for images. Script loaders should respect the fact that a vendor has consciously chosen '''not''' to support parallelism for script-inserted scripts. Providing a means by which this decision can be circumvented undermines their choice. I believe it was in that spirit the specification leaves eager fetching script resources as a suggestion.

			</blockquote>

	[[User:Getify\|Getify]] 21:39, 23 December 2010 (UTC)		[[User:Getify\|Getify]] 21:39, 23 December 2010 (UTC)

Getify: response about `async`

2010-12-23T21:39:16Z

response about `async`

← Older revision		Revision as of 21:39, 23 December 2010
Line 154:		Line 154:
	== Modify the specification so parallel-loading is configurable ==		== Modify the specification so parallel-loading is configurable ==
	The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.		The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.

			=== response ===
			Nothing about this proposal requires any parallelism that the browser wouldn't already afford. The spirit of this proposal is not about loading behavior, but about execution order.

			The spec says nothing about the parallel loading, nor do I think it should necessarily. All modern browsers HAVE in fact implemented parallel loading for all scripts, regardless of async or not. And I think this is a good thing. But it has nothing to do with `async` or my proposal to make the definition of `async` symmetric/consistent between markup script elements and dynamic script elements.

			The spec already defines that `async` is specifically to create unblocking of the page's resource loading AND "as soon as possible" execution of the script. But it only defines this for parser-inserted (markup) script tags. I think this is short-sighted, because I think a script-loader should be able to opt into either ordered or unordered execution in the same way that markup script elements can. That's really all the main proposal is about.

			[[User:Getify\|Getify]] 21:39, 23 December 2010 (UTC)

Serverherder: /* Encourage Vendors to Adopt the Current Performance Suggestion */

2010-12-23T21:14:14Z

Encourage Vendors to Adopt the Current Performance Suggestion

← Older revision		Revision as of 21:14, 23 December 2010
Line 152:		Line 152:
	The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.		The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

	== ~~Encourage Vendors to Adopt~~ the ~~Current Performance Suggestion~~ ==		== Modify the specification so parallel-loading is configurable ==
			The specification expresses the reasons parallel loading should not be done. To this point, allowing developers a means to '''require''' resources be downloaded in parallel is in direct opposition to the spec's all ready stated position. To this end, I see no purpose for async=true: A browser that hopes to be highly performant should implement the spec's suggestion to improve performance. Developers should not be able to circumvent the vendor's attempt to be conservative in its use of bandwidth simply to achieve ordered execution.
	~~Yes!~~

Serverherder: /* Encourage Vendors to Adopt the Current Performance Suggestion */ new section

2010-12-23T21:09:44Z

Encourage Vendors to Adopt the Current Performance Suggestion: new section

← Older revision		Revision as of 21:09, 23 December 2010
Line 151:		Line 151:

	The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.		The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

			== Encourage Vendors to Adopt the Current Performance Suggestion ==

			Yes!

Serverherder: /* The Current Suggestion Should be Changed to a Mandate */ new section

2010-12-23T21:09:08Z

The Current Suggestion Should be Changed to a Mandate: new section

← Older revision		Revision as of 21:09, 23 December 2010
Line 147:		Line 147:

	Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.		Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

			== The Current Suggestion Should be Changed to a Mandate ==

			The spec is pretty clear on why it chose to make this optional. If dependent script loading is so common that browsers that adopt the suggestion enjoy considerably better performance, the user will eventually decide to opt for those implementations. On the other hand, if it is more common that scripts are created and never inserted, leading to wasted bandwidth and clogged fetching queues, the converse will occur. Either way, by making it optional, the spec hedges its bet and is more prone to be future-proof as the habits of script developers evolve.

Serverherder: /* Vendors Should Implement the Existing Suggestion */ new section

2010-12-23T21:03:17Z

Vendors Should Implement the Existing Suggestion: new section

← Older revision		Revision as of 21:03, 23 December 2010
Line 143:		Line 143:

	- James Burke		- James Burke

			== Vendors Should Implement the Existing Suggestion ==

			Since the spec all ready includes a suggestion to download resources when the SRC attribute is set, parallel loading is an option the '''vendor''' chooses to implement and not something a script loader should be able to require. Vendors that don't implement the suggestion will run the risk of being less performant in these situations. That, however, is '''their''' choice to make as the spec suggests. If the benefits of parallel loading dependencies are so great, users will opt for this in their choice of agent or vendors can adopt the existing mechanism.

Serverherder: /* RequireJS order support */

2010-12-16T01:52:49Z

RequireJS order support

← Older revision		Revision as of 01:52, 16 December 2010
Line 132:		Line 132:
	I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify\|Getify]] 20:06, 15 December 2010 (UTC)		I have to admit, you raise a valid point with respect to that common usage. The YUI model (where the framework is responsible for all loading) is perhaps the more appropriate model to move toward, though. Or, the framework doesn't auto-load its own dependencies at all. In either case, I think it's cleaner to have one loading mechanism in play rather than two or more competing ones, because as you point out, this is going to get messy. I still am not sure this means that the async=false proposal is lacking, because as I think about how complicated such a split loading would be with your `readyState` proposal, that seems even worse/more complicated to me. [[User:Getify\|Getify]] 20:06, 15 December 2010 (UTC)
	</blockquote>		</blockquote>
			<blockquote style="background-color:#eee">

			I would not argue '''against''' a global queue for synchronized execution, I just think the usefulness of such a construct declines as scripts that "I don't care about" are added. It's my opinion the spec should provide the ability for high-level code to implement similar constructs, regardless of how complex it may be to do so. <br/>
			<br>
			That being said, I don't think it's any more complicated than existing models. Here's a demonstration of an [http://digital-fulcrum.com/executionorder/ IE-only parallel-loading, synchronously-executing script queue] implemented in 40 lines of code. It tests both cached and un-cached scripts (from the LABjs test suite) and has been tested and found to be working in IE6-8.
			<br>
			[[User:Serverherder\|Serverherder]] 01:52, 16 December 2010 (UTC)
			</blockquote>
	</blockquote>		</blockquote>

	- James Burke		- James Burke