Not all browsers have JavaScript. Some non-visual browsers won’t use it. And you cannot rely on JavaScript existing even in visual browsers. Even if the viewer leaves JavaScript turned on in their browser, there’s a very good chance that some functionality will be turned off. Mostly, this is because JavaScript is commonly abused by scammers.
Many people have pop-up blocking turned on, for example, so that they don’t get advertisements popping up on their computer; most browsers have this option built-in because the problem is so widespread.
Some browsers let the user choose exactly what JavaScript functionality to allow, from the ability to resize windows on.
When going over this tutorial in early 2007, I discovered that the very simple first example didn’t function at all in two out of three of the then-major browsers. I’d chosen setting the text in the status bar as the first example because it required only a single line and because its result was so obvious. No longer; most likely the functionality was abused by phishing sites. As far as I can tell, the ability to see changed status text is no longer available in most browsers.
Browsers will also attempt to detect whether your script is consuming too many resources on the client computer. If the browser detects this, it will either automatically stop your script, or present the viewer with a dire warning that the script is likely doing something wrong, and do they want to cancel? Most likely they will.
You cannot trust JavaScript at all. Not only can the viewer turn JavaScript off, but they can also change it. A JavaScript file is just like a web page: it gets downloaded to the client computer and then “displayed”. The viewer has full control over the file since it is on their computer, and malicious users can take advantage of this if you trust the “output” of JavaScript.
JavaScript should be used to assist the user, not to assist the server (or the webmaster). It should not be used to perform authentication, nor should it be used to calculate things that are then stored on the server. You would never want to calculate prices using JavaScript and then charge a customer based on that calculation, for example: you’ll end up giving some people a pretty hefty discount when they realize they can manipulate the calculation themselves. This does not mean that you cannot use JavaScript to show the viewer a quick summary of their prices or shopping cart total. It just means that you should, once they submit their purchase, calculate the prices on your end as well. Remember that on the Internet, it only takes one person to take advantage of security flaws in your web site.
JavaScript is a great feature for making your web pages easier to use. But it should not be used in place of server-side programming. Your pages should always be accessible to people who do not use JavaScript (it is difficult to imagine what a JavaScript would look like through a translator or a voice reader, for example), and you should not rely on the JavaScript calculations coming to your end intact and trustworthy.
Different web browsers, and different versions of web browsers, will often treat the same JavaScript slightly differently. This will be more of an issue the more complex your JavaScript becomes. Try to keep your JavaScript standard, try to test on a wide variety of browsers and versions, and make sure your web pages work if your viewers end up having to turn JavaScript off to bypass inadvertent bugs in your JavaScript. Remember that just because your code works now, there is no guarantee that it will work with tomorrow’s browsers. Keep things simple, and especially try not to “take advantage” of bugs in a browser’s JavaScript implementation. Someday that bug will probably get fixed.
If you look at other people’s web pages, you’ll notice that sometimes they’ll put JavaScript right inside their web pages, instead of putting it into a separate file as we’ve done here. I recommend against this. By putting your JavaScript into a separate JavaScript (.js) file, you can call the same file from different web pages. If a new browser version necessitates changing your JavaScript code to overcome a new bug, you’ll be able to make the change once, instead of looking for all the web pages you’ve used something like that code in. You’ll always miss at least one.
Separating your JavaScript into its own file also makes it much harder for your JavaScript to interfere with your HTML in browsers that don’t implement JavaScript, or don’t implement it the way you expect it to work.
You can put more than one <script src="..."> in your web pages, to reference more than one set of JavaScripts. Just make sure your JavaScript functions all have unique names.