[whatwg] Script preloading

[Jonas Sicking]

On Tue, Jul 9, 2013 at 12:39 PM, Ian Hickson <ian at hixie.ch> wrote:
> The proposals I've seen so far for extending the spec's script preloading
> mechanisms fall into two categories:
>
>  - provide some more control over the mechanisms already there, e.g.
>    firing events at various times, adding attributes to make the script
>    loading algorithm work differently, or adding methods to trigger
>    particular parts of the algorithm under author control.
>
>  - provide a layer above the current algorithm that provides strong
>    semantics, but that doesn't have much impact on the loading algorithm
>    itself.
>
> I'm very hesitant to do the first of these, because the algorithm is _so_
> complicated that adding anything else to it is just going to result in
> bugs in browsers. There comes a point where an algorithm just becomes so
> hard to accurately test that it's a lost cause.
>
> The second seems more feasible, though.

FWIW, I don't really know what functionality you put in the first
category, and what you put in the second.

However, as an implementor, I definitely think that the current
proposal is more complicated to implement than the proposal that I
pushed for before. I.e. adding a "noexecute" attribute on the <script>
element which causes the script element not to execute when it
normally would. Instead it fires the "load" event when the script has
been loaded and does nothing more.

Once the page wants the script to execute, it would call a new
.execute() function on the script which would cause the loaded script
to execute. If the function is called before the load event has fired,
an InvalidStateError exception would be thrown.

I could absolutely believe that this is harder to specify than your
proposal. I haven't looked at the spec in enough detail to know. But
it's definitely easier to implement in at least Gecko. I'd be
interested to hear what other implementors think. And implementations
have a higher priority than spec writing in the hierarchy of
constituents.

I also think it's a simpler model for authors to understand.

Now, even higher priority in the hierarchy of constituents are
authors. So if your proposal above is written with the goal of
creating something authors prefer over the noexecute proposal, then
that definitely seems like the right goal. I haven't read enough of
the feedback here to get a clear picture of if the proposal in this
thread is considered better than noexecute.

I could definitely see that the "dependencies" feature could be
attractive if it indeed would let authors avoid manually scheduling
scripts for execution. But as always when building high-level
features, there's a risk that if they don't solve the use-cases
exactly, that they won't get used.

/ Jonas