When adding client-side script to a web page, the JavaScript can be embedded directly within the page's HTML or provided via an external reference similar to include files in programming languages. When using JavaScript include files, the browser will cache the file so that it doesn't need to be downloaded on subsequent postbacks and page visits. By embedding the script directly wthin the page's markup, the script must be downloaded on each page visit (with the rest of the markup), which is wasteful if the script content is static. Therefore, JavaScript include files lessen the amount of data the client must download, improving the end user's experience. So JavaScript includes are a Good Thing. In fact, when using certain ASP.NET Web controls (like validation controls, the Menu, and so on), script includes are used to inject the necessary client-side plumbing).
JavaScript includes have a simple enough syntax:
<script src="pathToJavaScriptFile"></script>
Of course, XML rules allow for elements with no inner content to use “/>” as a shortcut rather than needing the closing tag. In a recent project I assumed this would work for JavaScript includes and added a number of includes using syntax like:
<script src="pathToJavaScriptFile" />
Well, guess what? That doesn't work, at least not in Internet Explorer. IE ignores the JavaScript include altogether, not sucking in any of the JavaScript content from pathToJavaScriptFile. If your JavaScript file contains only infrequently-used functions, you of course don't find this out until you perform some action that calls one of these functions in pathToJavaScriptFile and you end up getting a script error. And then, of course, you spend the next hour pouring over the JavaScript code and the page's rendered markup to find what's wrong, not realizing that the browser hadn't sucked down the JavaScript include file because you used “/>” instead of “</script>”.
What's particularly odd is that if you use a tool like Fiddler to inspect the HTTP traffic, the browser still makes a request to pathToJavaScriptFile! It just doesn't 'execute' the script or 'register' the functions if you end the <script> reference with “/>“ instead of “</script>“. Ditto if you fail to end the <SCRIPT> element (that is, if you have <script src="pathToJavaScriptFile">).
Long story short - make sure you don't make the same mistake I did. Save yourself an hour of frustration by adding the verbose “</script>” when externally referencing a JavaScript file instead of trying to save six bytes by omitting it.