Talk:JavaScript

Useful URLs to use for further work [1] and Inheritance through Prototypes

Suggestions for this page, Jan 2006

I came to this page for a better explanation of JavaScript and, hopefully, some indication of what the filenames would be on a Windows system. I need to know this as I can't get JavaScript working in Opera and all the Opera and other help files I have read have been useless.

So, perhaps some general info on JavaScript files would be helpful.

What filenames? The Opera forums are a good place to find Opera-specific help for all purposes.

I don't know if an encylopedic entry is really the place for what you're trying to ask, either.

(Also, sign your message with four tildes.) b0at

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. Jo r 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)[reply]

____

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)

defineSetter/defineGetter

These two functions, used in the article to create private variables, are not in the ECMAScript standard, nor E4X. A quick search didn't bring up any documentation for them, either. They aren't supported by Internet Explorer, so I wouldn't call them a de facto part of the language, either. I'll leave a note in that section. --Quamaretto 02:10, 2 Jun 2005 (UTC) (whoops)

No, they are not part of any standard. They were Mozilla extensions, and (I think) they still work in the newest versions of Netscape, as well as in other implementations that use SpiderMonkey, ie: JavaScript OSA. func(talk) 18:17, 1 Jun 2005 (UTC)

...and Konfabulator, as well. :) func(talk) 23:01, 1 Jun 2005 (UTC)

Hierachies without prototyping?

I don't see the value of this technique or the mention of it. Inheritance is supported directly through prototyping. (Nearly same thing can be done in C, or any other language with function pointers.) Opinions? --Quamaretto 02:09, 2 Jun 2005 (UTC) (whoops)

Yeah, its a bit of an odd example, isn't it? Some things in this article seem almost hostile toward the prototype-based nature of the language. This example:

this.BaseFunction = function()
 {
   alert("Base::BaseFunction()");

where they've used the double colon operator from some class-based languages seems forced and not particularly useful. Of course, the "JavaScript 2.0" people have been moving away from prototyping as well. func(talk) 23:00, 1 Jun 2005 (UTC)

If no one objects, then, I may add some more about prototyping. I've written a few thousand lines of it at work recently (AJAX, for better or worse) and it needs to be explained. --Quamaretto 02:10, 2 Jun 2005 (UTC)

window part of DOM?

The following sentence in the text would lead one to believe that the windows object is part of the W3C DOM:

For example, in a browser, typical host objects belong to the DOM (window, form, links etc.).

That can't be right, can it?

Change it if you want; all common browsers implement a window object in the DOM, and the term DOM commonly refers to any and all of the DOMs, not just w3c. --Quamaretto 29 June 2005 22:15 (UTC)

Confusing example

In the example code following "JavaScript supports inheritance hierarchies through prototyping", all of the names used are what the type of thing is -- the base class is called Base, and so forth. While this is useful as a summary to somebody who already knows how Javascript works, it only confuses me. I'm spending all my brainpower just figuring out what's a reserved word!

I'd suggest either: changing the class/function/variable names to something boring-but-easy-to-distinguish (like the old standby Vehicle, Car, drive(), etc.), or find some way to visually distinguish reserved words (like making them bold).

(Once I've figured out the Javascript object model, I'll gladly try to improve the examples myself, but I don't feel qualified just yet. :-)

I'll improve it tonight or tomorrow, I promise. But you'll have to remind me. And you'll have to come to my house to do that. :) I'm at work; otherwise I would do it right now. But that stuff is obfuscated and weird; in reality, JS OO can be used just like normal class-based OO. --Quamaretto 29 June 2005 22:12 (UTC)

comments on "usage" section

From the article:

JavaScript embedded in a web browser connects through interfaces called Document Object Model (DOM) to applications, especially to the server side (web servers) and the client side (web browsers) of web applications. Many web sites use client-side JavaScript technology to create powerful dynamic web applications.

This doesn't make much sense (and is quite hard to read, too). JavaScript isn't typically used to connect to web servers (except when using AJAX/XMLHttpRequest techniques). It certainly doesn't connect to the web servers through a document object model. You can't say it connects to "the client side [..] of web applications", as it is a part of a web application, and because the typical use of JS today is not web apps, but small things like those described in the next paragraph of the article.

The author probably wanted to say JS is used in client-side scripting to modify the page through DOM and to send requests to web servers via XMLHttpRequest. That's what the next paragraph is about though, so I'm unsure what to do with this sentence.

It may use unicode and can evaluate regular expressions (introduced in version 1.2 in Netscape Navigator 4 and Internet Explorer 4). JavaScript expressions contained in a string can be evaluated using the eval function.

It should either be moved to the language features section or removed altogether.

Last, AJAX and DHTML are not "design methodologies". I couldn't find a general word for them, but it's more of a "popular technique, using JS+DOM".

--asqueella 23:29, 10 July 2005 (UTC)[reply]

Debugging JavaScript code

I changed the intro paragraph in the error handling section. I consider JavaScript debugging nowadays not as difficult as it used to be. It would be nice if somebody else could add some information how the situation is while using Visual Studio or Eclipse. Hirzel 19:56, 24 August 2005 (UTC)[reply]

Passing by value Vs. Passing by reference

In the "Functions" section, there is a line that says "Basic data types (strings, integers, ...) are passed by value wheras objects are passed by reference.". I believe this is incorrect - objects like primitive types are passed by value, but it is a reference to the object that is passed. I think this statement should be edited.

Added

The term 'passed by reference' is pretty common and is only misleading if taken out of context. When read together, the meaning of passed by value and passed by reference is as clear as need be.

If further explaination is required, a full explaination should be given on what passed by value and passed by reference mean.

OzFred 00:41, 2 November 2005 (UTC)[reply]

My two cents

In JavaScript objectreferences are passed by value. In some languages, like C++ or VB you can have e.g.:

ByVal L As Long
ByRef L As Long
ByVal O As Object
ByRef O As Object

in an argumentlist. Numbers 2 and 4 are passed by reference, and assigning a new long integer or object reference will modify this value in the original variable. Numbers 1 and 3 are passed by value and modifying them has no effect outside the function - I believe this to be JavaScript's behaviour. In cases 1 and 2 a long integer is passed, in cases 3 and 4 an object reference; as you can see all four combinations are possible. You cannot pass an argument by reference in JavaScript, although you could emulate it like so:

function refvar(x)
{
  this.val = x;
}

function modifyit(x)
{
  alert(x.val);
  x.val = 42;
  alert(x.val);
}

var myrefvar = new refvar(12);

modifyit(myrefvar);

by noting that although object references are passed by value, their members are passed by reference. Hope this ends all possible confusion (if there was any) for ever. Bye! Shinobu 00:52, 10 November 2005 (UTC)[reply]

Use of for..in

The text for 'for..in' suggests:

"This loop goes through all enumerable properties of an object (or elements of an array)."

The reference to elements of an array seems to infer that for..in is a suitable method for getting the elements of an array without the added caution that for..in will loop over all enumerable properties. For example, a programmer may overwrite the push() function of Array.prototype.push to ensure that older browsers have it. If for..in is then used on an array, one of the returned properties will be the push() method/function.

Given that arrays are just a special type of object, the parenthesised bit should be dropped and the grammar cleaned up:

"This loops through all enumerable properties of an object."

One excuse for using for..in on an Array is to get the elements of a sparse array without iterating over the entire length. In that case, a normal Object would likely be much more efficient.

public/private

@By default, all members of an object are public. There are no private or protected members (though these can be emulated).: What is meant by the phrase by default here? Consider the following declarations:

var privateVar = 42;
this.publicVar = 42;

"this." isn't even shorter than "var". Better would be to say something like: private members are declared like this, public members like so. Shinobu 00:34, 10 November 2005 (UTC)[reply]

Too much

Is this an encyclopaedia entry or is it a Javascript tutorial? This should be cut back by vast amounts.

It's surely not intended as a JavaScript tutorial, but you see, you can't really discuss a programming language without delving into it's syntax. Is this a bad thing? I don't think so - there are a lot of misconceptions about JavaScript (many of those are caused by bad tutorials on the web) and we can eliminate those by presenting a clear picture of the language. I've seen the statement that "JavaScript doesn't support private members" too often to be funny - even on this page before I edited that out. Stating in the article that JavaScript supports private members eliminates this misconception, but you need a code sample to prove your point. Since people can actually see with their own eyes how it works this adds to the credibility of the article. So you want to discuss closures? If you don't mention them, the article fails to mention one of the defining properties of JavaScript. If you do mention them, the shortest and cleanest way to explain the concept is through a code sample. As long as we structure the information in an appropriate way we need not necessarily be afraid that we've got too much of it. Shinobu 02:06, 29 December 2005 (UTC)[reply]

Fragmented object discussion

The material about objects is fragmented between the following sections:

3.4 Objects

3.4.1 Creating objects

3.4.2 Constructors

3.7 Functions

3.8 Functions as objects and anonymous functions

Also ugly is that 3.4.2 uses a concept from 3.7. Also in 3.4.1 the new Object() declaration is syntactically the same as using a constructor. I propose a new section hierarchy:

Objects
Explain objects as a concept. More JS specifics.
- Creation
  Simple creation. If you need private members use a constructor (explained later).
Functions
Short description
- Functions as objects
- Anonymous functions
- Constructors
- Etc.

Constructors should mainly be about the fact that you can use private members and that you can execute code on object creation. A problem is that when you talk about objects, you want to have talked about functions before to be able to explain members, but if you talk about functions you want to have talked about objects before since they are objects. Perhaps the objects and functions should be discussed together, introducing concepts in a more pedagogicly appropriate order. Shinobu 01:57, 29 December 2005 (UTC)[reply]

Neat, huh?

I think it's kinda neat that the JavaScript interpreter is actually...a web browser!! The Immediate window equivalent is typing something like the following into an address bar:

javascript:alert("Hello World")

I don't know about you, but I think it is cool.

FLaRN2005 23:09, 31 December 2005 (UTC)[reply]

By the way, you can download HTML-Kit if you want to experiment. It's great!

Separate article for syntax

I propose creating a separate article for the syntax details, along the lines of the C and C syntax articles. The JavaScript article would offer at most a brief summary of the syntax, while the JavaScript syntax article would go into further detail.

I may tackle this myself, sometime soon, but I wanted to raise the notion first. It may require some reworking afterwards to find the right line of separation between the two articles.

Personally, I find a syntactic quick-reference to be of great use, especially when having to work with multiple languages on a regular basis, and I think the information is appropriate for Wikipedia. But ideally, these details shouldn't be in the way of others who don't need them, and they shouldn't weigh down the article as a whole.

--Flash 21:12, 7 January 2006 (UTC)[reply]

Javascript or JavaScript?

Mozilla folks call it Javascript. Which capitalization is correct?

"JavaScript" is correct when referring to the original thing as developed by Netscape, but makes it seem to the untrained eye more related to Java than it really is. I think it's okay for the article's title. "Javascript" is good for referring to any given implementation of it, kind of like the differingly-defined but all-encompassing "url". b0at 03:17, 8 January 2006 (UTC)[reply]

According to the SAP website: "JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.". Sun refers to it as "JavaScript" (see: Sun Trademarks). For encyclopedic purposes, I think it'd have to be referred to by the official Sun version. If there are accepted arguments in favor of calling it "Javascript", a brief mention of that could be added to the article. --Flash 05:15, 8 January 2006 (UTC)[reply]