Geek Answers Handbook

What are the disadvantages / problems of including scripts in the body of the page, and not in the head element?

There is already posted a record of the pros / cons of javascript placement inside the <head> element against right before the body tag tag ( </body> ).

However, I have seen that sometimes developers put JavaScript code in arbitrary locations on an HTML page. This seems to be due to laziness. What are the disadvantages of embedding JavaScript code in arbitrary page locations? There are a number of obvious disadvantages, such as lack of caching, less reuse, etc. What other flaws can you come up with in this regard?

Thanks at asdvance.

+7
javascript
source share
4 answers

Read this:

http://groups.google.com/group/closure-library-discuss/browse_thread/thread/1beecbb5d6afcb41?hl=en&pli=1

The story that we do not want to wait for DOMContentReady (or, even worse, a load event), as this leads to a bad user experience. The user interface is not until all DOMs have been downloaded from the network. So the preferred way is to use the built-in scripts as quickly as possible.

 <div id="my-widget">&lt;/div> <script> initWidget(document.getElementById('my-widget')); </script>

Yes, it is not so simple but it leads to a better user experience. By deliberately leaving the DOMContentReady wrappers, we have managed to prevent the use of Google Apps to use this template.

And this:

Using DOMContentReady is considered Google anti-pattern

+5
source share

Whenever you place a script element on a page, regardless of where it is located, unless you use the defer or async attributes, and the browser that your visitor uses supports them, all HTML parsing ends, and control is passed to the JavaScript interpreter (waiting for the script file to load if the script is in a separate file). This holds back the rendering of your page. Therefore, unless you have a really good reason to place the script tag in a different place, placing the script tag at the very bottom of your page will improve its apparent load time.

Of course, there can be really good reasons. For example, if a script has to use document.write to output HTML to a page (as many ad scripts do), then of course this should be where this HTML code should go. Similarly, if you have a button in the user interface and you attach a handler to this button, which calls your script, if the script is further on the page, there may be a window of opportunity for the user to click the button before your script processes the click. Doing nothing or not getting an error that adversely affects the user's work.

If your page is fully functional without any script (good practice for most general purpose sites), with the script just increasing your experience, put the script at the bottom. If the script is critical to the functionality of your site (a perfectly acceptable practice for some sites and, of course, for many web applications), it is best for your build process to combine all of your custom JavaScript into one file, reduce it, and link it in head so that you get the job done as short as possible. (If your script relies on libraries, you can download them separately from the CDN for speed, or add them to your custom code, depending on your rating, which will be faster for your users.)

This is all speed / perceived speed argument. From the point of view of separation of attention, make sure that all your JavaScript is in separate files (at least in separate source files, you can create a build process that combines your JavaScript into your HTML to create an output file for the user without breaking the separation problems, but then you cannot get your JavaScript caching if you use it on multiple pages). If you have a separate JavaScript file, you will have to link to the script somewhere, I don’t think it really matters a lot to split points of view, where as long as you don't have script elements littered throughout the HTML source .

Edit : see also David Murdoch's answer , specifying Google by the value of the built-in script blocks for connecting the user interface. I wanted to refer to him, but could not find him; he did. This is a pain because (if you do not do it with a build script), it really confuses the separation of problems. Above, it shouldn't be that hard to do with tags and build a script ...

+4
source share

The most obvious drawback for me is that if it is a framework, the members are inaccessible until it is downloaded and parsed. Consider the following scenario:

 <html> <head> <script type="text/javascript"> $(document).ready(function () { /* ... */ }); </script> </head> <body> <!-- rest of content --> <script type="text/javascript" src="jquery.1.4.2.min.js"></script> </body> </html>

Of course, you get the error "$ is undefined". All code that relies on this script should follow it in order of execution (unless you use timers, the defer attribute, or the window.onload event).

Outweigh the flaws as far as I can see.

+1
source share

This is the same principle as CSS. In how separation and markup are separated using stylesheets with your HTML, the functionality and markup should be separated, including your JavaScript outside, and not embedded with your HTML elements.

In addition, less code is being rewritten. Seriously, who wants to write

 <input type="text" onfocus="$(this).css('background', 'yellow');" />

for each input element, when is it easier to write all this functionality once?

 $('input[type="text"]') .focus(function() { $(this).css('background', 'yellow'); }) .blur(function() { $(this).css('background', 'white'); });
+1
source share

More articles:


All Articles