[Webkit-unassigned] [Bug 50115] Please implement async=false for dynamic script loading (REGRESSION: LABjs is broken)

Thu Dec 30 11:35:56 PST 2010

https://bugs.webkit.org/show_bug.cgi?id=50115

--- Comment #50 from Kyle Simpson <getify at gmail.com>  2010-12-30 11:35:55 PST ---
> So, currently, there isn't a compatibility problem to solve.  There's only a 
> performance problem to solve, correct?

Wrong. As of earlier this morning, that's what I thought. But it turns out even if they were using the cache-preloading, they still wouldn't *currently* break in Webkit, because of what I discovered and explained in comment #46.

>> There's quite a bit of performance optimization that will be lost on these 
>> sites if they are forced to go back to using script tags and abandon using 
>> script loader techniques.
> Is this statement backed up with experiments or just intuition?  

It's not intuition, it's provable/experimentable fact.

Regular markup script tags *do* load in parallel, yes. But that's only a small fraction of the web performance optimization that's possible.

I've explained the 2 primary (performance) advantages of script loaders using dynamic script elements over regular script tags many times, including on the W3C list and bugs. But I'll restate them here for completeness.

> 1. Markup script tags *block* many other page-load activities, like
> downloading/rendering of images/css/etc, DOMContentLoaded/DOM-ready events,
> etc. Even though they may load in parallel to each other, because of
> document.write(), the browser must be pessimistic and must force everything
> else on the page to wait in case a document.write() is found in one of the
> scripts.
> 
> 2. There are potentially HUGE performance advantages to on-demand or
> lazy-loading techniques, where a page-load can be optimized by reducing to 
> the bare minimum (or none at all!) the scripts that are loaded during the 
> initial page-load, and instead putting off until later the loading (or 
> execution) of such scripts. By getting content in front of users quicker, 
> the perception of page-load speed is greatly improved, which improves user 
> satisfaction on sites.

And even if you want to completely ignore the performance advantages that dynamic script tags have over script loaders, there's still the module dependency management concern, which is that sometimes you dynamically (on-demand) load one or several modules in response to user actions in the page. You can't do that with regular script tags in markup, because the page has already been parsed. You *have* to use dynamic script tags. And if you have more than one script to load, you may very well run into this unordered execution pitfall.

> Antti's point, which I'm not sure you understood, is that "parallel load, 
> sequential execute" is WebKit's default behavior if you have a bunch of 
> script tags

No, I fully understand Antti's point. It's apples and oranges though. What a set of script tags can do in markup is not particularly relevant to what a set of dynamically created script elements can (or in this case, CANNOT) do in JavaScript.

The fact, whether we like it or not, is that dynamically created script tags DIFFER completely from markup inserted script tags, in their ordering behavior. And dynamic script loaders almost exclusively use dynamically created script elements via JavaScript.

As described above, dynamic script tags are far preferable to most script loaders because there's several performance advantages to them over markup script tags.

So, Webkit's "parallel load, sequential execute" default beahvior is all well and fine, except that it ONLY applies to markup script tags, and not to dynamic script tags, which isn't helpful to me, or any other script loaders for that matter.

> We should be agreeing on behavior in the HTML working group and then 
> implementing those agreements.  Trying to end-run the process by sneaking a 
> patch into WebKit isn't really productive.  

I am not trying to end-run the process at all. That's a ridiculous miscontruing of my actions and intent. I'm a complete outsider and this is my first foray into this world of specs and browser functionality. And to be honest, it's all completely opaque, obtuse, confusing, and frustrating.

I tried long and hard to work it out in the W3C comment threads and on the WHATWG wiki page. The long and short of that process thus far basically reveals that the spec process wasn't convinced this use-case was valid, and that input from, and 2 independent implementations by, browser vendors would be the likely next step before spec progress could continue. Mozilla was the first. And since Webkit was making a change that was also going to break LABjs, Webkit seemed like the likely second candidate to work this out with.

Now you tell me that I'm jumping the gun by coming to Webkit. You'll have to forgive me if I throw my hands up and cry "Shenanigans" here. I'm not trying to "tail-wag-the-dog", but depending on who I talk to, I get completely opposite advice.

Some people say that the spec should decide first, and the browsers should follow. Others say the browsers should experiment and when they agree on something that works, then the spec will codify it.

I have no idea how it should really work. But I do know this. If each group points the finger at the other (as is currently happening), deadlock is GUARANTEED.

Plus, you saw Ian's comment #40. He's basically responding (subtely) to the question of if the browser should wait on the spec, and saying "if you think it's a good idea, go ahead."

Now, you may not think it's a good idea, which we're trying to hash out. But suggesting that we have to wait on the spec SEEMS pretty counter-productive in this case.

>> I assume you mean the markup `async` attribute, not the (currently being 
>> discussed) `async` property on a dynamic script element in JavaScript?
> Today these two things are the same.  The JavaScript property reflects the 
> DOM attribute, like a ton of other JavaScript properties.

Wrong. These two things are NOT the same, and that's my whole point! The `async` attribute in markup can be present or not present, and that alone is enough to control the ordering behavior of that script tag with respect to other script tags.

But the `async` property in JavaScript on a dynamic script element CANNOT control this ordering behavior. The property is NOT fully consistent with, nor is it symmetrical to, the attribute.

If you examine a reflected JavaScript property of an existing markup-defined script element, it *will* indeed reflect `true` or `false` properly.

But, and here's the key, if you dynamically create a script element via JavaScript (not via markup), that `async` property is completely dead and useless. It doesn't default to `true` to indicate that this script will in fact have the same unordered behavior as a markup script tag with `async` attribute flagged on. And you can't change it to `true` or `false` to control it.

So, NO, the `async` attribute and the `async` property are definitely NOT the same.

My request is to ****make them much more the same****. My request is that the `async` property on a dynamically created script element (not from markup) reflect `true` for async, since that's how it will behave, and that I be able to change that value to false if I want it to behave "not async" (that is, ordered).

> Why don't we create an API that solves this particular problem 

This idea has been brought up several times. In fact, I don't have a huge problem with the idea of a new API, except that it is obviously going to be a lot more complicated than to tweak the existing mechanisms.

The chances of designing a whole new loading API and getting all the browsers to agree on it anytime soon are practically zero. LOTS of work and further discussion and arguing about API preferences and syntax styles and all that junk will be had before anything like that sees the light of day.

By contrast, async="false" has a very small footprint of change compared to that. It piggybacks on an existing mechanism. It extends it in what I think is a very logical, consistent, and symmetrical way (as described above). AND, it's already been implemented, tested, and proven in one browser. That automatically puts this idea further along in the horserace than any other yet-to-be-designed new loader API.

> instead of goofing up the connection between the async property and the async attribute?

I wholeheartedly disagree, as I just explained, that we are "goofing up the connection" between attribute and property. They *are*, as currently implemented (and spec'd) GOOFED UP and inconsistent, and I'm trying to make them consistent and un-goofed up.

>> http://trac.webkit.org/changeset/67245
> I'm not sure I understand the connection with this change.

This change is why we got into this whole discussion in the first place. Because ostensibly, Webkit was going to disable the only viable "preloading" mechanism available to a script loader (the "cache preload fake mimetype" trick), which they rely on to be able to achieve the intended parallel-load, serial-execute behavior.

"Cache preloading" enables the use-case in a hacky round-about way by pre-caching all the scripts, then re-requesting them (from cache) with proper script tags, in the desired order.

By Webkit removing the ability to do "cache preloading", and NOT enabling the use-case in another straight forward facility/mechanism, you are neutering script loaders like LABjs.

> Bottom line: Let's work this issue out in the HTML WG.  That's the proper 
> forum for this discussion.  Once we decided what to do in that venue, we can 
> implement that decision here.

Again, that would be fine EXCEPT that I've already tried that and they essentially, in a round-about way, have said that browser vendors need to have more input and implementations to give better spec guidance.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.