Talk:JavaScript/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

Untitled

Useful URLs to use for further work [1] and Inheritance through Prototypes — Preceding unsigned comment added by Hannes Hirzel (talk • contribs) 20:36, 20 December 2001 (UTC)

The relationship between EMCAScript and JavaScript

ECMAScript? I have never heard of it. Anyone knows the reason that we should name the article ECMAScript instead of widely-known JavaScript? -- Taku 07:06 Feb 25, 2003 (UTC)

ECMAScript only defines the core of JavaScript. Maybe it's good to put JavaScript-specific parts into JavaScript. -- Nanshu 11:21 Feb 25, 2003 (UTC)

Agreed. I bet most of people expect an independent artcile about JavaScript. Remember the principle of least surprise. The title should be the most familiar one not educational. If usage is wrong (like Harakiri), if it is common, the title should be it. -- Taku 16:03 Feb 25, 2003 (UTC)

ECMAScript is just the standardized version of JavaScript, so I think the main article should be at JavaScript. ECMAScript can either redirect to JavaScript, or can have information specifically about the standardized version (e.g., what is or is not in the standard, how the standard came about, etc.). --Zundark 22:09 Feb 25, 2003 (UTC)

Ok now. Then could some sysop rename the title to JavaScript? -- Taku 22:16 Feb 25, 2003 (UTC)

Done, this time with history intact. --Brion 02:38 Feb 26, 2003 (UTC)

ECMAScript is not JavaScript, seems to me that its better to have an article making the true relationship between ECMAScript and JavaScript clear and then linking to all of the various ECMAScript implementations (there are more than JavaScript and JScript) than to perpetuate the myth that ECMAScript and JavaScript are one and the same. McClade 17:23, Mar 8, 2004 (UTC)

There is no 'myth', ECMAScript is the standardized form of JavaScript/JScript. Therefore JS should be treated as what it is, an incomplete implementation of the ECMA core with nonstandard (but wide-spread) additions. Chopping off JavaScript from this article makes no sense to me, you might as well chop off HTML 4.01 transitional from HTML 4.01 strict in the HTML article then. Jor 17:49, 8 Mar 2004 (UTC)

JavaScript was the basis of ECMAScript but there as some very good reasons for keeping the two seperate. For example, I'm currently working on an interpreter for the new CCXML standard. The spec for CCXML specifies the use of ECMAScript within CCXML documents, meaning that when we came to write our interpreter we were free to use any ECMAScript language we liked. We could've used JavaScript, JScript (there are differences), FOSI, or even writen our own. More importantly our competitors could have done the same. Using a standard like ECMAScript is the only way the W3C people could ensure portability of scripts without tieing people into one implementation.

The same situation exists in Web Browsers. Netscape uses a JavaScript interpreter, IE uses JScript and Opera uses a more pure ECMAScript interpreter with some extensions to support JavaScript and JScript. All three browsers use different languages and so support some different code, but all three are ECMAScript complient and will run true ECMAScript code. ECMAScript is very important in its own right, seperate from JavaScript and so deserves a seperate entry in the Wikipedia. McClade 22:51, Mar 8, 2004 (UTC)

ECMAScript, I believe, was once the basis of JavaScript. In the era of Internet Explorer 3.0 and Netscape Navigator 2.0, both parties developed their own versions of JavaScript, and the major part of it was made into ECMAScript, which contained the best features of both parties. --x42bn6 11:02, 23 Jun 2005 (UTC)

May I just quote MSDN? It makes this subject all perfectly clear.

JScript? JavaScript? ECMAScript? What's the Deal Here?

You may be confused by the term ECMAScript that I've been using in
this article. You're in good company. Here's the deal. ECMA
(European Computer Manufacturers Association) is a European-based
association for standardizing information and communications
systems. The standard recently approved, known as ECMA-262, is
based on joint submissions from Microsoft and Netscape.
JScript 3.0 is Microsoft's implementation of the new ECMA-262
scripting language. JavaScript is a scripting language written by
Netscape that preceded the ECMA standard. Basically, when talking
about JScript or JavaScript, we are talking about implementations
of the same standard scripting language, ECMA -- the
implementations are just marketed by different companies.

--tyomitch 17:57, 1 September 2005 (UTC)

____

What about JScript for .NET? Is it just planned or is it in an SDK somewhere? --Hirzel 19:51 9 Jul 2003 (UTC)

JScript is the Microsoft version of JavaScript, it is not the same thing.

--ThatNateGuy 22:33, 23 May 2005 (UTC)

---

How exactly is script-commenting "forbidden" with XHTML or XML? I think what this means is that the scripts just won't run if they're in a comment. I'm changing it in the article, just wanted to point it out here. -- ESP 05:27 20 Jul 2003 (UTC)

I believe it's because you cannot put '<' and '>' within <script> tags, because they are considered 'tags' that are not closed. In fact, with XHTML, you need to put '\<' and '\>' in place of '<' and '>' to acheive compliance. Unfortunately, neither of the replacements constitute valid JavaScript comments. --x42bn6 11:02, 23 Jun 2005 (UTC)

It's because whatever is inside a script element should be valid script. There is no need for HTML comment delimiters inside a script element (it is invalid JavaScript and only tolerated by browsers in certain circumstances).

For XHTML, the W3C specification says to use:

  <script type="text/javascript">
    <![CDATA[
    ... unescaped script content ...
    ]]>
  </script> 

[w3c XHTML Specification] Rgqld 06:39, 25 October 2005 (UTC)

---

AFAIK the User interaction and Events sections are not really part of JavaScript, but rather of the DHTML DOM. For example, when using JavaScript on the server side one cannot use the functions listed in the User interaction section, nor the events which are specific to DHTML DOM objects.

Inheritance

One other issue may be the example given for inheritance. The problem lies with the statement:

Derive.prototype = new Base();

This statement causes the construction of an instance of Base, and assigns this instance to be the prototype for Derive. But what if the constructor of Base needed to receive parameters? For example, consider the following:

function Base(attributeA) {
 this.attributeA = attributeA;
}

function Derive(attributeA, attributeB) {
 this.constructor = Base;
 this.constructor(attributeA);
 this.attributeB = attributeB;
}

d = new Derive('red', 1000);
alert(d.attributeA);
alert(d.attributeB);

It is not possible to do this using the Derive.prototype = new Base() notation.

Also missing is some expansion of the explanation of the scoping rules (i.e., functions define a new scope for all internally declared function and variables), and some reference to the object specifier this. --RoySharon 10:27 13 Aug 2003 (UTC)

---

Isn't KJS suppoed to be called NJS? And the link is http://www.bbassett.net/njs/ I don't know, just asking.

---

It would be useful to include a section on "JavaScript Security Issues"

---

Is there enough reference material in this article to make a WikiBook out of it? I'd like to write a few notes about the different ways javascript can be used (e.g. using spidermonkey to embed it in your applications) and a bit on the relative power of javascript, perhaps a link to the Paul Graham article, but it feels a bit overpowered by some of the many details we have of programming this language. Ojw 21:39, 22 Jan 2005 (UTC)

Be aware that there are JavaScript 1.5 Guide and JavaScript 1.5 Core Reference at developer.mozilla.org, in wiki format. The first of the two resource is a comprehensive book on the topic, so I'm unsure if it's reasonable to start another one, unless you would like to focus on the differences between Mozilla and Microsoft implemntations. --asqueella 23:36, 10 July 2005 (UTC)

Variables and Math

I removed these three sentences from the article, under the heading "Variables":

This makes it easier to use variables than in some other languages, but results in some problems in math.
For example, the JavaScript calculation 81.66*15 will give 124.899999.... instead of 124.9.
This is because there are no specifications on precision.

The last two sentences are fine, but they would need to go into a different kind of section, perhaps if we added a "Critism" heading or something. (Also, it would need to be pointed out that this is a common critisim of implementations that rely on the IEEE floating point standards).

The first sentence is some kind of flaw in someone's reasoning. What does the nature of JavaScript variables have to do with "problems in math"? Its preceeding sentences were discussing scope and dynamic typing, niether of which affects mathematical precision.

func(talk) 01:56, 12 Feb 2005 (UTC)

Well spotted.

The first sentence is rubbish - the easy type conversion has nothing to do with the precision of JavaScript numbers. The second sentence is not an example of type conversion but of the fact that IEEE-754 Doubles can't exactly represent all decimal fractions.

The third sentence is also rubbish - numbers in JavaScript are represented in binary as IEEE-754 Doubles. It has nothing to do with precision, which is a measure of repeatability. As far as I know you can do 81.66*15 as many times as you like and will get exactly the same answer every time, making the maths highly precise. If a programmer fails to account for the small variances between IEEE-754 Doubles and decimal numbers, errors may be introduced (i.e. loss of accuracy, not precision). This often happens when trying to format decimal numbers: Convert to 2 decimal places. 203.5.10.172 00:59, 2 November 2005 (UTC)

Concerning E4X

"has partial support of E4X, which is the fourth revision of ECMAScript." this is wrong E4X is an language extension defined in ECMA-357

OK, I changed it to:

...has partial support of E4X, which is a language extension dealing with XML, defined in the ECMA-357 version of ECMAScript.

is that correct? func(talk) 21:24, 12 Apr 2005 (UTC)

Almost. The only thing that was slightly wrong is "ECMA-357 version of ECMAScript". ECMA-357 is not a version of ECMAScript. It's a separate standard, defining a few extensions to ECMAScript, which can be applied to different versions of ECMAScript. I updated the sentence. --asqueella 23:02, 10 July 2005 (UTC)

History of JavaScript

I found these bits in FAQTs [2]:

Netscape's LiveScript was actually derived from CEnvi. CEnvi was a powerful yet easy to use interpreted version of the C programming language developed by NOMBAS (http://www.nombas.com). Of course, NOMBAS has since changed the name of its language to ScriptEase(TM) and expanded the implementation (marketed as ScriptEase Desktop) significantly, particularly to conform to the ECMA standards and to ensure cross-platform compatibility.

I wonder if it is true and whether we should add these bits to the LiveScript article (instead of redirecting). --minghong 03:32, 27 Apr 2005 (UTC)

This is really fascinating; something that I've never heard of before. We need information on it somewhere. func(talk) 20:40, 29 Apr 2005 (UTC)

JavaScript in wikis

(maybe the wrong place to ask, but here I go) Does Wikipedia support JavaScript? Phlebas 19:42, 29 Apr 2005 (UTC)

Do you mean JavaScript that could be added by a user? No, that would represent a horrible security risk, given that anyone can edit a wiki page. I shudder at the thought. JavaScript is used by Wikimedia software, however, which you can see by looking at the source code of a page. You can also use Bookmarklets to assist you in your Wikipedia editing experience, (if you know how). func(talk) 20:38, 29 Apr 2005 (UTC)

Yes, exactly what I meant. It would mean total mayhem. Phlebas 21:58, 29 Apr 2005 (UTC)

It does support whatever Javascript you put in your user monobook.js. I'm currently trying to get it to work. I did at least get Hello world to work. Spalding 21:43, July 13, 2005 (UTC)