To allow optional JavaScript download, some widely used JavaScript libraries, such as jQuery and requireJS, use script elements added to the document dynamically by JavaScript. (Of course this feature is also used by applications directly as well). For normal deployment this approach works well in practice. At development time however, or in the presence of network or server problems, the approach gives poor error recovery information. Fundamentally the problem is that the insertion mechanism has no error return path.

The script element does support one event, 'onload' which fires after the script has finished loading. I suggest the addition of one new event, 'onerror', which fires in every other case. For examples, a network error (4XX, 5XX) or JavaScript parse error would trigger onerror but not onload. On the other hand, a runtime error for the outer-function of the script element would trigger onload (I guess), but the developer can handle this with try/catch.

Very long load times would still have poor error recovery information, but developers could implement UI to signal "loading..." once they know they will get some update event eventually.

jjb

Reply via email to