Scripting

The information published in this post is now out-of-date and one or more links are invalid.

—IEBlog Editor, 21 August 2012

We received some good questions about how the JScript engine works in IE.

• What version of JScript is supported?
  The version of JScript included with IE6 is EcmaScript edition 3 compliant. I’ve seen some confusion recently with some even claiming that we do not support EcmaScript. In fact JScript, JavaScript and EcmaScript are all basically the same language with a different name. At one time Netscape used the name LiveScript before adopting the name JavaScript even though it was not related to Java. EcmaScript is the name for the standard recommendation for the language from the ECMA industry association.
• Why is there a choice of scripting languages?
  The implementation of the document object model in Internet Explorer is separate from the scripting engines themselves. As a result you can use different languages such as JScript or VBScript using the language attribute of the Script tag. <SCRIPT language=”VBScript” > for example will invoke the VBScript engine. Support for the VBScript syntax has been popular with developers familiar with visual basic particularly in corporate environments. It’s best not to confuse the language functionality with that of the Document Object Model (DOM) in IE. When we refer to the DOM we are talking about the ability to manipulate the HTML document with methods such as document.createElement whereas a JScript method is more language specific such as the indexOf method. See the references to see the different capabilities of DOM versus the JScript and VBScript languages.
• What is the default scripting language?
  The language will default to be JScript for the page unless otherwise specified. Once you have specified a language that will be the default language for the rest of the page unless you explicitly change it again. In general unless you have good reason to use specific capabilities of the languages I advise people to stick to just one script language on a page as it will avoid confusion, ease maintenance and also avoids the overhead of having two different script engines loaded.

There was an interesting comment from Jim in December on this blog where he asked if we support the Content-Script-Type header and meta element as described in the HTML 4.01 specification. This is good feedback and certainly something we may wish to get to in the future. However as no other browser implement this or implement multiple scripting languages at this time we will be concentrating on other more pressing issues with our support for standards in the foreseeable future.

Hopefully this clarifies a little about out support for scripting engines. While we are on the topic it’s also worth reminding people of a previous post on this blog on script debugging in IE.

Thanks
-Dave

Comments

• Anonymous
  January 01, 2003
  JavaScript support in IE is just fine. While there is some lacking in the DOM, I can usually get done what I need to. On that note, I'd like to request XPath support ASAP. :)
• Anonymous
  January 01, 2003
  "... at this time we will be concentrating on other more pressing issues with our support for standards in the foreseeable future"
  
  Thank you!!
• Anonymous
  January 01, 2003
  Umm... if you're trying to continue support for standards then why would you try to confuse people with another name for EcmaScript? Just drop JScript as a name and always refer to it as EcmaScript since they're the same thing according to you. Heck... at least people can say that IE does support at least one standard.
• Anonymous
  January 01, 2003
  Umm... if you're trying to continue support for standards then why would you try to confuse people with another name for EcmaScript? Just drop JScript as a name and always refer to it as EcmaScript since they're the same thing according to you. Heck... at least people can say that IE does support at least one standard.
• Anonymous
  January 01, 2003
  Hmm, you could do better with that advice. It should really be in general unless you have good reason to use specific capabilities of the languages I would advise people to stick with JScript/JavaScript/EcmaScript in order to ensure your script can be run in any browser (there are users out there that use browsers other than IE, y'know?)
• Anonymous
  January 01, 2003
  Why are you continuing to make JScript the default scripting language? Why not make JavaScript the default, as that is the language that is supported by most other modern browsers and the only scripting language that can be reliably used on the WWW.
  
  Also, what exactly does IE obey in order to change the scripting language in use? If I include type="text/javascript", does that change it to JavaScript or do I need to include the deprecated language attribute (which I won't do, BTW)? What about support for application/x-javascript or application/x-ecmascript (or application/javascript and application/ecmascript as they will be when "Scripting Media Types" becomes an RFC.)
  
  Does IE obey the HTTP content-type header field for scripts or does it perform more broken content type sniffing? eg. If someone includes a script and specifies a type="text/jscript" attribute, yet the server sends Content-Type: application/javascript, which engine will IE use? JScript or JavaScript?
  
  Can you let us know a little about which standards are and are not going to be implemented? How about better support for the standardised DOM and what about (somehow) phasing out support for useless proprietary extensions like document.all, innerHTML and other non-standard extensions you've forced other browsers to implement. eg. You could issue a scripting warning about the use of such extensions when the user has the script debugger enabled, just like FF does for document.all in the JavaScript Console.
• Anonymous
  January 01, 2003
  Why would anyone want to phase anything out? Who cares about whether they add to the standard?
• Anonymous
  January 01, 2003
  I really wish Netscape had stuck with the name LiveScript, it would make life so much easier when trying to explain how Javascript and Java are nothing alike.
  
  Anyhow, Lachlan, I don't think you understand why MS stick with "JScript." Essentially, Netscape came out with Javascript, and people started using it. Microsoft, in their effort to compete, needed to support Javascript. For some reason or another (I bet it was related to trademarks), they called their implementation JScript. Most people who need to know what Javascript and JScript are (the same language), but many of those people have no idea what ECMAScript is, or even that ActionScript is another implementation of ECMAScript.
  
  If Microsoft suddenly started referring to JScript as ECMAScript, it would cause no end of confusion and an awful lot of "OMG M$ are droppeng teh Javascript!!1one Teh m0n0p01y!" Ultimately, Javascript/JScript/ECMAScript is one of those languages with a colourful history.
• Anonymous
  January 01, 2003
  Lachlan: "what about (somehow) phasing out support for useless proprietary extensions like document.all, innerHTML and other non-standard extensions you've forced other browsers to implement."
  
  innerHTML is NOT useless, a point proved by the fact that developers have widely used it, and other browsers have therefore adopted it.
  
  MS do not 'force' anyone to do anything. Mozilla et al are free to choose not to implement MS's de-facto standards - though such short-sightedness would clearly hurt them.
• Anonymous
  January 01, 2003
  The LANGUAGE attribute is deprecated. TYPE is used these days...
• Anonymous
  January 01, 2003
  > In fact JScript, JavaScript and EcmaScript are all basically the same language with a different name.
  
  Does JScript support Javascript language features such as catchguards and function expression statements that do not appear in the ECMA-262 specification?
  
  I think that saying they are "basically the same language" is a bit of an oversimplification. Javascript and JScript both implement the ECMA-262 specification, but the three entities are not identical.
  
  > However as no other browser implement this or implement multiple scripting languages at this time we will be concentrating on other more pressing issues with our support for standards in the foreseeable future.
  
  I understand & agree totally.
  
  > what about (somehow) phasing out support for useless proprietary extensions like document.all, innerHTML
  
  I agree with Chris, I wouldn't describe innerHTML as being useless. Adding content to the page via createElement etc. takes quite a bit of code compared with innerHTML. I don't think that innerHTML should be dropped from Internet Explorer until after it supports DOM3LS.
  
  Something I'd love to see (but doubt it'll happen) is an annotated copy of each specification that Microsoft claims to implement, noting deviations and omissions. I believe I've seen that done with another browser, but can't recall which one.
  
• Anonymous
  January 01, 2003
  Yeah, replace <SCRIPT language="VBScript" > with <script type="text/vbscript"> ;)
• Anonymous
  January 01, 2003
  The comment has been removed
• Anonymous
  January 01, 2003
  Also the comment on ECMAScript, JavaScript, and JScript being the same language is not accurate.
  
  JScript and Javascript are both supersets of ECMAScript, which though supporting the full ECMA Script specification introduce additional DOM and proprietary functionalty.
  
  I wish JScript and JavaScript were the same language, then I could stop having to code seperate event handlers for each. Of course that would require IE to support the DOM Events spec properly, which it doesn't.
• Anonymous
  January 01, 2003
  In fact, innerHTML is now supported for XHTML documents in Mozilla. (That is correct, XHTML documents send as application/xhtml+xml.)
• Anonymous
  January 01, 2003
  That's interesting, Anne. Have they allowed document.write as well? Last I checked, people were complaining that this wasn't possible because you could introduce malformed XML that way (something I don't particularly agree with; the document.write/innerHTML could always raise an exception if that happened).
  
• Anonymous
  January 01, 2003
  Ken,
  
  Technically the DOM and event handlers are not part of the language. They are language independent APIs provided by the host.
  
  No matter how big the differences are in the DOM and event handlers, it doesn't amount to a change in the language.
  
  For instance, JScript in Internet Explorer and JScript in IIS/ASP are exactly the same language, but the objects exposed by the host are different - you don't get Server or Session objects in Internet Explorer, for example.
  
  This doesn't mean there aren't actual differences between Javascript and JScript; I mentioned a couple above, and I agree with your basic point.
  
• Anonymous
  January 01, 2003
  I would like to add my voice to those of Ken Kolano and the others who have expressed distaste for retaining the language attribute for the script tag.
  
  It's very important for IE7 to support all current W3C recommendations FULLY. This includes fixing IE6 bugs, as well as eradicating proprietary stuff. I want to see Microsoft retake the lost market share to FireFox.
• Anonymous
  January 01, 2003
  Any chance to look at garbage collection (or explain the current implementation)?
  
  DOM, DHTML, XMLHttpRequest etc. are getting more popular / mature, leading to pages that don't get reloaded so often - hence effective GC is more important.
  
  There's some commentary on "The Internet Explorer Memory Leak Problem": http://jibbering.com/faq/faq_notes/closures.html#clMem and more here: http://www.dotvoid.com/view.php?id=23
  
  Suggests IE uses reference counting for GC. Mozilla seems to have a more advanced GC mechanism now, using mark and sweep. Some notes http://jpspan.sourceforge.net/wiki/doku.php?id=javascript:gc
  
  Thanks
• Anonymous
  January 01, 2003
  Scott wrote:
  "I want to see Microsoft retake the lost market share to FireFox."
  
  If that ever happens, then IE's development would just become stagnant again (meaning they will have no reason to implement the standards), as it has been for the last 4 years. You seem to be forgetting that the reason IE7 is coming out (though, MS will probably deny this) is because of the competition Firefox and other browsers have brought back.
  
  I for one want to see IE lose this monopolistic market share, regardless of any standards support they'll be implementing. Maybe once the playing field is level again, we'll see some real IE development happen!