script element with a
src attribute. We will look at both of these methods inside this section.
As there might be several different types of script available to use on web pages in the future, it makes sense to add the name of the script you are using as a MIME type:
Note: You will find script examples on the web that have a
src attribute to your script element:
Upon meeting this element in a page, browsers will then load the file
myscript.js and execute it. Any content inside the
script element itself will be skipped when you provide a
src attribute. The following example will load the file
myscript.js and execute the code in it, but will not execute the alert inside the
script element at all.
- You can easily find your script if you need to modify it, avoiding the need to scan through long HTML documents to find the place to fix a problem.
- Fixing errors becomes easier as a debugging tool or error console will tell you which file contains the error and reliably report the line number.
However, the development benefits of this are diminished by the effect this has on the performance of your document. This differs slightly from browser to browser but the worst-case scenario (which is sadly enough still the second most-used browser) does the following:
- Every time the browser encounters a
scriptelement, it will pause rendering (displaying) the document.
srcattribute (if you use a script on another server you also have to wait until the browser finds that server).
- It then will execute the script before it goes on to accessing the next one.
All of this means that the display of your web site is slowed down until all of these steps happen for all the scripts you include. This can become annoying for your visitors.
One way around this is to use a backend script to create a single file from all the files you use. That way you have the benefit of keeping maintenance easy while simultaneously cutting down on delays to your web page display. There are several scripts like this on the web — one of them is written in PHP and available from Ed Eliot.
The classic best practice for placing scripts was in the
head of the document:
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> <script src="myscripts.js"></script> </head> <body> <!-- lots of HTML here --> </body> </html>
The drawbacks are that your scripts delay the display of the document and that the script does not have access to the HTML in the document. You therefore need to delay the execution of any scripts that change the HTML of the document until the document has finished loading. This can be done with an onload handler or one of the various DOMready or contentAvailable solutions out there on the web — none of which are bullet-proof and most of which rely on browser-specific hacks.
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> </head> <body> <!-- lots of HTML here --> <script src="myscripts.js"></script> </body> </html>
It is up to you to choose what fits the purpose of your website; you could even choose to do a mixture of both — put the scripts with very important functionality in the
head, and call them in conjunction with the “nice-to-have” scripts at the end of the document.
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title></title> <script src="myimportantscripts.js"></script> </head> <body> <!-- lots of HTML here --> <script src="myscripts.js"></script> </body> </html>
Every script on the page has the same rights — all of them can access each other, read out variables, access functions, and also override each other. If you have a function called
init() in your first included script, and another one in your last included script, the original one will be overridden. We will come back to this problem in the best practices article of this course.
Scripts can also read cookies; using the
Whereas packing and obfuscation are useless as security measures, they are often done on medium and large scripts before the code is put live on the web as part of the publication process. This helps to cut down on the amount of bandwidth required to serve the site to its users. Saving a few bytes here and there may not seem significant on your blog about kittens, but it can add up to massive savings when you are dealing with a site with usage figures like those of google.com.
Techniques to avoid
document.write()— you can write out content to the document using
document.write()but there are several issues with this: you mix HTML and scripting and you need to add a script node exactly where you want the content to appear, which slows down your page. It is a very cool way of easily showing (for example in a tutorial or when testing/debugging your code) what the result of some piece of code is, but it is a bad example to show people, as you should never have to use it in live code.
<noscript></noscript>— as its name implies, the
noscriptelement is the opposite to the
document.all— both of these solutions were the DOM equivalents in old browsers (Netscape 4.x and Internet Explorer 4 respectively) and unless you need to support those (sorry if you have to) this is unnecessary code.
- What does the following link do and what problems can that cause?
- Providing parameters for scripts is a powerful way of making them reusable. It is very important to keep the option to provide compact and easy to use parameters. What are the downsides of the following solution (which provides parameters that are compact and easy to use)?
<script src="badge.js"> var color = 'blue'; var background = 'yellow'; var width = 400; </script>
- What is the issue with so called “global variables”, and how can they be avoided?
- Where in the document would you put a large script that is nice to have but not vital to the functionality of the site? Why?
- What is the problem with executing scripts like this: