In writing client side code to run across all web browsers we need to take into account the fact that while all web browsers that support client side processing except for Internet Explorer can run JavaScript, IE itself can only run vbScript or jScript and cannot actually run JavaScript. This is not an insurmountable problem for us though because JavaScript can for the most part be considered to be a subset of Jscript. Any code that we write in JavaScript that runs on browsers that support JavaScript can also (with slight modifications) run on Internet Explorer as well.
This doesn't mean that all of JavaScript also works as jScript because there are still differences between the two languages such as JavaScript's use of event listeners while jScript uses attachEvent to serve the same purpose. What it does nean is that almost everything that can be done with JavaScript can also be done with jScript and by incorporating feature sensing into our code we can modify our JavaScript code so that it will also run as jScript.
The mistake that many people make though is to start with some jScript that works in Internet Explorer and then try to modify it so that it will also run as JavaScript in other browsers. The difficulty that they run into in doing this is that JavaScript does not have equivalent commands to all the jScript commands and there are a great many things that can be done with jScript that cannot be done with JavaScript.
When setting out to write code that will work cross browser it is therefore important that you first start with JavaScript and modify it so that it will also run as jScript since if you try to start with jScript there are no guarantees that there will ever be a way to get the same thing to work in JavaScript.
For those things that can be done with jScript that do not have JavaScript alternatives there are two possibilities. If the jScript is accessing things outside of the web page (such as files or the clipboard or other web sites) then there will be no way to produce the same effect in JavaScript as security restrictions on the web mean that such things ought not to be done in the first place. Those jScript options are intended only for use on intranets where full control over the client computers is available. If on the other hand the jScript is just producing some effect within the web page itself then it may be possible to create some JavaScript code to do the same thing. Such code is certain to be significantly larger than the jScript and perhaps will require hundreds of lines of code to do in JavaScript what can be done in one or two lines of jScript.
While not all JavaScript commands have identical jScript commands each command that isn't identical in the two languages have equivalents in jScript to every JavaScript command which requires about the same amount of code. It is therefore reasonable to think of Javascript as a sub set of jScript since by using feature sensing with that code we can build scripts that work in both. The fact that there are so many jScript commands that do not have JavaScript equivalents means that jScript is a far more powerful language than JavaScript and removes any possibility of our considering the two languages to be exactly equivalent (and certainly it is impossible to consider jScript as a subset of JavaScript as at least one person has tried to suggest).
