If you use defer and the user performs actions in a partially rendered page, the code that tries to execute something from a deferred script before it is has finished loading will generate errors for the user. This is baffling to users, and the only recovery action is to load the page again. The error message they get is usually something vague about a function or variable being undefined. They don’t have any way to know that the undefined something may not have loaded yet, so they may even repeat the same process and get the same error. The safest approach is to include script references earlier in the page whenever possible and avoid using deferred loading. This will make it more likely that the browser has your script code when the user starts interacting with the page. Of course, even this isn’t a guarantee. To protect yourself from errors caused by early user interaction with a page, you can include a top-level piece of code to disable elements that might depend on load order. This way, you can avoid triggering the use of code that is still being fetched. For example, you can disable a Submit button in an HTML form to prevent the user from clicking it and needing some associated validation scripts before they are available.
If you allow users to interact with a page before all the script code has been downloaded, it will appear to them that the page is ready to be used. By temporarily disabling the postback, you can ensure safety and also allow users to enter their data on the page while the scripts continue loading in the background.
In addition to the perceived performance advantage, some applications also temporarily disable elements of the form that cause a postback in order to avoid a complication with a security feature of ASP.NET. Some controls can be registered for validation, and ASP.NET will round-trip the set of valid values set for that control. The possible values are hashed (a cryptographic signature is calculated on them and later validated after postback) and round-tripped along with the values so that the server can detect any attempt by malicious code to submit something other than the valid list of values. Because the set of authentic values has to be collected while the page is being rendered and may not be fully assembled until after the form has been fully rendered, the hashed data is included after the closing form ele-ment. When a specific web form is fairly large or complex, the set of validation values can also be large, so it is possible for the user to interact with the form and submit it before the browser receives the validation data. The browser would then be unable to submit the set of valid values back to the server, and the user will see an error when the page is posted back on the server and the validation values are missing. So, to prevent this scenario, you can disable the postback until you’re sure that the browser has received all of the validation values.
In Listing 3-2 (from Enable.htm), the Submit button is disabled initially in the HTML markup. The script element contains a function to enable the Submit button along with a line of script for attaching the function to the window’s onload event. Thus, the button will be disabled initially and then enabled after the whole page has been loaded.
Notice that I only disabled the Submit button. My first inclination would be to disable the entire form and have everything in it disabled, but that would not be portable to all the browsers. In a real application with several elements that might cause a postback, you would have to initially disable all of them and then enable them during the onload event.