Talk:JavaScript syntax

Inaccuracy (needs citation)

The following statement: "else statements must be cuddled (i.e. "} else {" , all on the same line), or else some browsers may not parse them correctly." found in section 5.1 is incorrect. I have been programming in javascript for 4 years, and have never used that programming style. I have yet to notice any browser incompatibilities. If this statement is true, please provide a citation. - Kickboy 04:07, 24 August 2006 (UTC)

The statement is not present anymore.

Can we delete this block from 2006? 87.191.37.170 (talk) 07:26, 9 December 2022 (UTC)

Inheritance without prototyping, etc.

I removed that part because it isn't syntax, it isn't very useful or common in modern times, et cetera. That and the preceding section need some clarification, as it is long and some ground is covered multiple times, but I'm not up to that right now. Quamaretto 03:19, 20 February 2006 (UTC)

Biased views

I am a bit surprised about Quamaretto's behavior. He tends to throw away contributions that dont fit into his view of JavaScript. I am currently unsure if I should waste my time contributing to WikiPedia if it is so easy for others to impose their biased view upon others.

As far as the most relevant sources are concerned, you were apparently right about the origin of the syntax regarding Java and other languages, and I left the original quote in the article. (The first time I removed your material, I assumed that you were trolling or didn't have a relevant source since you didn't present one. That change is my bad, I guess.)

As far as the other material, you should see the article WP:NOR and others in WP:What Wikipedia is not. There are sound reasons for all of those. The language comparison section is original material you wrote to demonstrate your point—, which was plainly already demonstrated by the quote.

Basically, I corrected your changes to present the relevant information you gave, as well as to preserve the stated rules of Wikipedia. There's no reason to get upset over that. Quamaretto 00:02, 28 April 2006 (UTC)

Look at the large amounts of example code in the sections below. For example the assignment section. Is it really a good idea to present tons of scarcely commented examples to the reader ? Is it allowed to confront users with vast amounts of example code, but not allowed to explain to them that assignment and operators were taken over from C with almost no change ? Before presenting lots of boring examples, I wanted to give the reader a rough orientation scheme about what to expect.

The second reason for listing up the origins of the syntax elements was to introduce the reader to the subject of JavaScript syntax. There was none.

Another observation which leaves me speechless is that my introduction gets thrown away, while other commercial artifacts are kept. Look at the third paragraph of the JavaScript page. Look at the two links at the end of the paragraph. Link 2 may be justified (Sun Trademarks), but link 1 points to an unrelated Copyright page at SAP. This looks like commercial subversion to me. But maybe I just didnt understand the deeper meaning. Therefore, I left it unchanged because I thought I might have misunderstood it.

It is much easier to throw away contributions of others than to first try understand what they wrote. That's why WikiPedia is not ready to rival other valuable sources of information.

I don't know why the SAP link was included, other than that it repeats the claim on the Sun page. It isn't exactly a prominent place for advertising, so that isn't a likely motive.

Regarding with code with few comments, the goal is to write accurate encyclopedic material. Providing an easy introduction to the language is not. Yes, this page is a mess and needs improvement, but it was worse in the past.

On the introduction you wrote, see "Original Thought" above. There are rules; follow them and people won't revert your changes.

Anyway, don't think people are going to revert anything you write here. If you write anything else, I'll defer unless it's very clearly out of bounds. It would be helpful if you wrote a qualifying opening paragraph, or several, summarizing the features of the syntax. Pay attention to the guidelines and no one will probably bother you. Quamaretto 22:23, 28 April 2006 (UTC)

Missing Syntax Structures

This article could stand to mention function literals, regex literals, and possibly object prototyping. 08:10, 16 August 2006 (UTC)

The article is also lacking a discussion of the with() construct. (Not sure if it qualifies as a operator or a syntax, I think technically it is an operator).

How about additional uses of ()? Such as this syntax common with frameworks these days: (function() { ... })(); Ziemkowski 17:20, 12 September 2007 (UTC)

with() is a statement for changing scope chain. I don't know whether it can be counted a control structure.

() is function call operator. () after a function is only a function call syntax. (function() { ... })(); only is function expression syntax and function call syntax using together.--LungZeno (talk) 22:45, 27 January 2009 (UTC)

Good Job

This was a great article for someone in need of a quick reference on the specific differences between JavaScript syntax and the syntax of languages like Java and C++ for someone with experience in those languages and working on a small project in JavaScript.

Yes, thanks a lot to the author(s). Short and to the point. —Preceding unsigned comment added by 84.167.27.253 (talk) 19:02, 29 May 2008 (UTC)

Miscellaneous and reserved words

I think the Miscellaneous section could stand to be rewritten, and possibly re-titled to Parsing or something. We don't really need a level three head for the simple sentence "JavaScript is case sensitive." Also, JavaScript's reserved words should be added to the article. 209.92.136.131 21:37, 12 December 2006 (UTC)

Various

Variables : It says : "Variables in standard JavaScript have no type attached, and any value can be stored in any variable.". But when a value is assigned to a variable, its type is recorded - i.e. attached. Something like "A variable in standard JavaScript has no fixed type, and any type of value can be stored in any variable." perhaps? The value 0.1 cannot be stored exactly as a Number, so "any value" might mislead.

Suggest rephrasing (too convoluted?): Variables are variant types [link?no article yet] that can take any value of a small number of types [footnote#1], and which are converted or changed implicitly as needed. In effect, any value can be stored in any variable.
footnote#1: Number, String, Object, Boolean. Functions are Objects, and so can also be stored in variables]

Variables (2): It says: "...[in a function,] variables used without being declared with 'var', are global (can be used by the entire program)."
This needs clarification: Variables declared in a function do have global scope, but are not defined until the function has been evaluated, and a function cannot be evaluated -- at global scope -- until it has been declared. In effect, one must declare before use.
Re the example code: Any use of "twenty" causes ReferenceError until f has been declared, and called at least once.
Note that functions declared inside function scope can be called inside that scope before the source text appears. Again, variables declared without var in inner functions are not usable until the function is called.

Actually, it is a little more complicated that the above paragraph would represent. A variable simply used inside a function without specifying a scope MIGHT be global, but the javascript parser is supposed to start at the bottom of the execution context chain (i.e. the function in which the statement resides), and then iteratively search for a scope higher in the chain. So if you have nested functions, it is possible to use a variable without instantiating it with var but not be available globally, if there is an outer function in which that variable is defined. This is one of the concepts that make closures in JavaScript possible.24.49.69.72 17:50, 7 April 2007 (UTC)

Numbers : It says "... they do not always exactly represent decimal numbers, particularly fractions.". They can represent all integers up to 2⁵³ exactly. So "... they do not usually represent decimal fractions exactly."?

Strings : The character set is not presently mentioned - put "sequence of UniCode characters"? A third example might illustrate ' within "...", \t \n, \u03A3 for example. In MSIE6, and as I recall in ECMA-262, strings CANNOT be indexed as arrays.

Arithmetic : Plus is also a unary operator. It is useful for converting String (or Boolean) to Number : Count = +MyForm.Ctrl.value .

Comma : I see no mention of it. No example of a var list, nothing to support for (J=0, K=1 ; K<4 ; K++) {} which I hope is legal.

82.163.24.100 16:56, 31 January 2007 (UTC)

---

I see no mention of continue break label in connection with loops. 82.163.24.100 13:36, 29 October 2007 (UTC)

Multidimensional Arrays

This is really nice, but I think it would be good to have one paragraph on multidimensional arrays and some examples of declaring and using them since (at least for 2 dimensions) this is a very common usage. —Preceding unsigned comment added by 167.1.146.100 (talk) 12:59, 8 February 2008 (UTC)

"Modern Day" Prototyping

All major standards compliance browsers support __proto__ object in Elements, as well as __defineGetter__ and __defineSetter__. Perhaps this should be incorporated into the document? —Preceding unsigned comment added by Yhulkdsfdd (talk • contribs) 17:44, 11 September 2008 (UTC)

Since it's hard to determine what's in JavaScript or not because of the lack of a spec delineating differences from ECMAScript, I'm not sure we should mention __proto__, __defineGetter__, and __defineSetter__. --Maian (talk) 21:34, 11 September 2008 (UTC)

[edit] If ... else

Should it not be explained that the following:

if(x==1){
   something()
}
else if(x==2){
   somethingelse();
}

the else if works like a shorthand if (without {})

if(x==1)
  do something here

so really it is
if(x==1){
   something()
}
else{
   if(x==2){
      somethingelse();
   }
}

Sorry if that didn't make sense, I find it hard to explain.

To me, this is an implementation detail. Can you give an example of different behavior (from programmer point of view) between else { if(...){ } } and elsif(...){ } constructions? — Hypher (talk) 08:38, 20 March 2011 (UTC)

Bitwise

This needs to be explained. As the rest of the article explains everything in adequate detail, this is more like a list.

FAQ references changing

Sections of the CLJ FAQ are being reordered and convered from numeric anchors to textual ones. When that is finished, Wiki should be searched for such references to be corrected. I have updated the two in this Article. 82.163.24.100 (talk) 18:34, 12 October 2008 (UTC)

For loop: end-condition?

 for (initial;end-condition;loop statement) {
   /*
     statements will be executed every time
     the for{} loop cycles, until the ending
     condition is satisfied
   */
 }

The condition should be called while-condition, or just condition, but never end-condition. As in every C-like language, the for{} loop cycles while the condition is satisfied. --Como (talk) 14:28, 23 October 2008 (UTC)

No response in several months... I assume everyone agrees, so I dared to change the article. --Como (talk) 09:26, 3 March 2009 (UTC)

with no doubt

for(initial; condition; loopstatement) s;

is indeed syntactic sugar for

initial; while(condition){ s; loopstatement; } — Preceding unsigned comment added by 201.124.237.242 (talk) 09:05, 25 December 2019 (UTC)

Reworked Methods and Inheritance

Much of what is written about this on the web is wrong or misleading or too tangled up in browser semantics to be intelligable. So I have added succinct, non-trivial examples that highlight the issues. I learnt a bit in the process. All examples have been tested.

I hope others find this useful, particularly those comming from other OO languages that are quite different.

The article should probably be renamed to something like JavaScript Language rather than Syntax. Syntax without semantics is useless. But I think the contents is quite good at the moment -- a short sharp overview.

The JavaScript Prototypeing logic is quite bizzar IMHO. Classical Lisp IS-A links would be fine. But in JavaScript it is confused by C++ thinking. MyFunction.prototype is plain wrong -- it should simply be this.prototype = parent. No need for magic. Tuntable (talk) 07:47, 3 February 2009 (UTC)

For...In and Arrays: useable together or not?

The article states that For...In is not useable with arrays, but the W3Schools website gives arrays as an example of the use of For...In: http://www.w3schools.com/js/js_loop_for_in.asp and the Microsoft Developer Network specifically states that For...In can be used for "stepping through ... all the elements of an array", without giving any warning about unexpected results. (This is referring to JScript, rather than JavaScript, admittedly, and I don't understand the relationship between the two.) http://msdn.microsoft.com/en-us/library/kw1tezhk(VS.85).aspx FrankSier (talk) 15:44, 6 February 2009 (UTC)

I have done some research on this subject - not original research :) - and modified the article mainly by putting in some inline references. FrankSier (talk) 21:37, 7 February 2009 (UTC)

Method toFixed

Method toFixed should not be recommended for the web because it is unreliable in MS IE 7 and I think all previous versions of IE that had it - 0.07.toFixed(1) gives 0.0. The algorithm for StrU currently in http://www.merlyn.demon.co.uk/js-rndg1.htm#GC has no known errors. 82.163.24.100 (talk) 18:44, 3 April 2009 (UTC)

Internet explorer uses JScript, not JavaScript, it works with all JavaScript browsers. 72.152.120.17 (talk) 19:10, 4 March 2011 (UTC)

No, JScript, at this time, is ECMAScript 3, so is JavaScript 1.5. Confirmed by Wikipedia via a quote from Douglas Crockford: http://en.wikipedia.org/wiki/JScript#Comparison_to_JavaScript . --Hibou57 (talk) 20:09, 18 July 2013 (UTC)

alert vs. println

Is there a reason that println is used in the examples instead of alert? I like JavaScript on client and server, and code in it everyday (helps pay the bills), but I _wouldn't_ be coding in JavaScript if it wasn't for the ubiquitous web browser. Given JavaScript was invented as a browser scripting Language, would anyone be opposed to me swapping out println and replacing it with alert? I would also change the note at the top of the page noting how alert assumes any user who cuts and pastes the examples will be working in a browser. Jeremywosborne (talk) 21:02, 15 April 2009 (UTC)

Replaced 'println' reference with 'alert' function calls, along with reasoning for using 'alert.' Jeremywosborne (talk) 01:43, 22 April 2009 (UTC)

I was the one that replaced all the document.write/alert references with println. To me, JavaScript is just a language that just happens to be used most often on the web. I was trying to keep the article as specific to the language as possible, without complicating it with the DOM, which is NOT part of JavaScript. But I'm happy enough as long as there is a note explaining that document.write/alert is not part of JavaScript and is only used because the browser is the most common host of JavaScript. --Maian (talk) 07:50, 22 April 2009 (UTC)

Thanks for the response Maian. It's very difficult to create demonstrable JavaScript examples with the lack of a standard output function. After so many hours coding in this sometimes great, sometimes atrocious language, I figured I'd err on the side of making things browser compliant. Jeremywosborne (talk) 20:09, 22 April 2009 (UTC)

I use alert a lot. Why println? ElliottBelardo (talk) 21:03, 8 July 2013 (UTC)

Functions

The code could be changed to also illustrate the ternary operator ? : :

return diff > 0 ? gcd(segmentB, diff) : gcd(segmentA, -diff)

Since the code might be copied, it would be well to change it, after testing, to the more efficient method, in which the second argument to the internal gcd is either A mod B or B mod A, which is approximately equally easy to read; or to the wondrous non-recursive form :

function GCD(U, V) { // or HCF
  while (true) {
    if (!(U %= V)) return V
    if (!(V %= U)) return U } }

And, for the same reason, the alternative acronym HCF should be included. 82.163.24.100 (talk) 20:01, 24 July 2009 (UTC)

Native Objects

I have completed the list of Native Objects by reference to the Standard.

The page should not be allowed to get too long, and giving much detail on Native Objects would use a lot of space. How about a new page for JavaScript Objects, with the entries on the Syntax page being condensed to about the size of the first paragraph about Arrays? 82.163.24.100 (talk) 11:51, 26 July 2009 (UTC)

Add Description of the Math Object

This is my first contribution to Wikipedia anywhere. (-: So be kind to me! :-)
I have to own up to being a newby at JavaScript too though I have been in computing since the 1960s.

I would be grateful for any suggestions or comments about my attempt to insert a description of the Math object. The place where this appears (5.4) seems to need no more than this description does it? Perhaps there should be more elsewhere about doing arithmetic. E.G. There is no discussion of operator precedence.

Is the example at the end too complicated? I wanted to get several different methods into the same line of code. - Wogga62 22:55, 15 September 2009 (UTC) —Preceding unsigned comment added by Wogga62 (talk • contribs)

Well, first of all, I don't really like how this article is shoehorning the JavaScript API into an article about JavaScript syntax. I'd much prefer all that stuff moved to the wikibook.

With that said, I do like the table. It could use links in the description column, e.g. e (mathematical constant) (BTW, it's Euler's number not Euler's constant). And the example and the link to w3schools at the bottom is unnecessary.

--Maian (talk) 07:33, 18 September 2009 (UTC)

Constructors and Object Creation

The text claims that the constructor function called when instantiating an object (i.e., the function referenced from a "new" expression) is "not remembered." That is false in all major browsers: the "constructor" property of every object contains a reference to the constructor function. (Pointym5 (talk) 16:34, 29 December 2009 (UTC))

The fact that the constructor parameter list is optional in a "new" expression is not discussed. (Pointym5 (talk) 16:41, 29 December 2009 (UTC))

Characters allowed in identifiers

WHERE ARE THE RULES FOR ALL THE LEGAL BUT WIERD CHARACTERS IN IDENTIFIERS? (e.g. "$", "_", etc) —Preceding unsigned comment added by 24.129.93.200 (talk) 16:29, 16 September 2010 (UTC) (moved to new section)

Added to JavaScript_syntax#Variables: "An identifier must start with a letter, underscore (_), or dollar sign ($); subsequent characters can also be digits (0-9). Because JavaScript is case sensitive, letters include the characters "A" through "Z" (uppercase) and the characters "a" through "z" (lowercase). Starting with JavaScript 1.5, you can use ISO 8859-1 or Unicode letters (or \uXXXX Unicode escape sequences) in identifiers."—Machine Elf 1735 (talk) 00:18, 17 September 2010 (UTC)

Machine Elf’s edit is a good start, but it’s not entirely accurate. Digits aren’t limited to 0-9 — any character in the “Decimal digit number (Nd)” Unicode category is considered a digit. Also, a lot more characters/categories are allowed in identifiers. See http://mathiasbynens.be/notes/javascript-identifiers by Mathias Bynens: “An identifier must start with $, _, or any character in the Unicode categories “Uppercase letter (Lu)”, “Lowercase letter (Ll)”, “Titlecase letter (Lt)”, “Modifier letter (Lm)”, “Other letter (Lo)”, or “Letter number (Nl)”. The rest of the string can contain the same characters, plus any U+200C zero width non-joiner characters, U+200D zero width joiner characters, and characters in the Unicode categories “Non-spacing mark (Mn)”, “Spacing combining mark (Mc)”, “Decimal digit number (Nd)”, or “Connector punctuation (Pc)”.” There’s also a JavaScript variable name validator tool here: http://mothereff.in/js-variables 78.20.165.163 (talk) 11:29, 5 March 2012 (UTC)

Truthy and Falsey

"Truthy" and "Falsey"... feel free to source them and say something about them.—Machine Elf 1735 (talk) 01:09, 5 March 2011 (UTC)

Boolean section

I propose the boolean section be edited to be less confusing. I also propose that the ternary operator be removed from the section, because logical context is being misrepresented as type coercion, which it is not. The ternary (?:) operator is not an example of type coercion, nor is the negation operator "!". Furthermore, the page compares expressions instead of values, as there are infinite expressions, all unessential expressions should be removed from the section for clarity. 72.152.120.17 (talk) 06:36, 6 March 2011 (UTC)

Considering I've removed examples like true==true and false==false... if you have something specific in mind, please share, otherwise you're not proposing proposing anything in your opening sentence. I think it's a lot less confusing than it was here:

// Automatic type coercion
//Boolean operands will be converted to a number, if possible, or to a  string (if the other is a string)
alert(false == false); // true
alert(false == 0);     // true
alert(false == "0");   // true
alert(true == true);   // true
alert(true == 1);      // true   
alert(true == "1");    // true

// Type checked comparison
// No conversion of values
alert(false === false); // true
alert(false === 0);     // false
alert(false === "0");   // false
alert(true === true);   // true
alert(true === 1);      // false
alert(true === "1");    // false

Examples with "falsy" and "truthy" values.

alert(3?true:false);    // true
alert(true == 3);       // false
// 3 is logically true(known as "truthy"), as are all non-0 non-nan numbers. However, it is not "true", even with type coercion.
alert(!!null == false); // true
alert(null == false);   // false
// Two exclamation marks will convert anything into a boolean based on if it is truthy or not. However, automatic type coercion does not convert to booleans. null is falsy but not "false".

alert(false == +'NaN'); // false (shorthand for getting a NaN value)

I think some of the permutations could potentially be eliminated but it's necessary to show, for example, that neither true==2 nor false==2 behave the way one might expect.

The ternary operator's clearly appropriate for an overview of logical operations, Booleans, and automatic conversion. Are you seriously suggesting negation shouldn't be used?

“Furthermore, the page compares expressions instead of values...”

It obviously does both.

If you have constructive suggestions to enhance it's clarity, I'd like to hear them.—Machine Elf 1735 (talk) 08:33, 6 March 2011 (UTC)

You have too many examples, they don't demonstrate the important points. Logical context needs it's own section, it's a feature of the syntax, not of automatic type coercion by the equality operator. "that neither true==2 nor false==2 behave the way one might expect." That was already demonstrated. Type conversion by the ! operator is not the same as automatic type coercion. Again, these edits are harmful to the clarity of the article. Each aspect was demonstrated well before your edit. Type coercion was shown, as well as logical context. Each in their own separate code box. Let's not jumble two entirely different features of javascript into one box. That is definitely cause for confusion. 72.152.120.17 (talk) 16:35, 6 March 2011 (UTC)

PS: I may add that the ! operator belongs in the "Operators" section, not to booleans. 72.152.120.17 (talk) 16:42, 6 March 2011 (UTC)

As I said, I agree that some of the examples can be eliminated. I simply included the permutations because that's what you did... Needlessly, you more than quadrupled the original four examples: 1 and "0" for each.

Contrary to what you keep repeating, you did not provide an example that clearly demonstrates the behavior of a Boolean operand being automatically converted to number for comparison. Frankly, the terms "truthy" and "falsy" were irrelevant except in so far as the behavior is somewhat counter-intuitive:

In an equality comparison (non-strict, obviously) between a Boolean (on one side) and either a number or a string (on the other), the Boolean operand is converted to a number, rather than the non-Boolean operand being converted to a Boolean. Thus, a comparison between a Boolean and any number except 0, 1, (and NaN), or any non-empty string that can't be converted specifically to 1, (e.g. "0", "2", "3"...), won't behave consistently with the non-Boolean operand's so-called "truthy"/"falsy" behavior in logical contexts. For example, 2 is "truthy", (as in 2?true:false), but neither true==2 nor false==2 are true, because the Boolean is automatically converted to 1, and neither 1==2 nor 0==2 are true.

In addition to your 12 permutations of automatic v. strict comparison, you added a separate block: “Examples with "falsy" and "truthy" values”, making a peculiar example of the number 3, (rather than 2). In a line comment you say: “3 is logically true(known as "truthy"), as are all non-0 non-nan numbers. However, it is not "true", even with type coercion.” [sic]

In a Boolean context, 3 is always "true". Comparison is not a Boolean context. And comparison to a Boolean does not make it a Boolean context any more than comparison to a number makes it a numeric context, or comparison to a string makes it a string context. When 3 does get type converted (automatically or explicitly) to a Boolean, then it's always true, and never false, (whether or not that Boolean then gets discarded in favor of the original value, and so, arguably, wasn't so much "converted" as "interpreted"... just isn't the point.)

If you say 3?true:false is true and true==3 is false; you invite the assumption that false==3 is true, but that's false too. So no, you're mistaken when you say “That was already demonstrated.”

I'm not going to argue with you about whether logical context needs its own section, but it's clear to me that you do not understand “automatic type coercion by the equality operator”.

Your suggestion not to use the negation and ternary operators is inexplicable considering that you, yourself, used the ternary to demonstrate the so-called "truthiness" of 3, and double negation to show an explicit (obviously) conversion of a null to a Boolean. The suggestion that examples in the Boolean section should exclude these operators is just kind of strange and unhelpful, isn't it?

I'll give you an example of an edit “harmful to the clarity of the article”, your misleading comment: “shorthand for getting a NaN value”. Any string that can't be converted to a number would result in NaN, +"NaN" is not shorthand, NaN is shorthand.

“Each aspect was demonstrated well before your edit. Type coercion was shown, as well as logical context. Each in their own separate code box. Let's not jumble two entirely different features of javascript into one box. That is definitely cause for confusion.”

Argument by repetition isn't constructive. I think the section was fine before your last edit. And I think it demonstrating type conversion/coercion and various logical contexts... However, the examples didn't attempt to address the edge case which you made a point of in your edit.

You don't seem to understand the issue and so your examples were misleading. It's also clear you don't get it from: “Each in their own separate code box ... Let's not jumble two entirely different features of javascript into one box”. Demonstrating strict v. non-strict comparison doesn't require 12 examples (four was more than enough). The edge case is when Boolean and non-Boolean operands are used in a non-strict comparison but what you said was: “Examples with "falsy" and "truthy" values.”. Now, when you say “demonstrated well before”, I suppose you think that you demonstrated each aspect, (and well, if you do say so yourself), otherwise, why would you more than quadruple the number of examples, if you thought each aspect had been demonstrated long ago? Still, your edit wasn't all bad, the "truthy"/"falsy" jargon is nice to have... It's just that you can't give examples of it with no introduction.

The section is about Booleans. As we all know, they're closely related to logical contexts. The section is not about type conversion. The section is not about automatic v. strict operators. The section is not about implicit v. explicit conversions. If you'd stop trying to twist it into something it's not, I'll remove some of the unnecessary permutations.—Machine Elf 1735 (talk) 08:53, 7 March 2011 (UTC)

Try to make your posts more compact. First: I said it is not "true" which means it does not == true. Truthy is not the same as true. Type coercion generally refers to the == operator, type conversion relates to the not operator, boolean function, etc. Also, note that you added most of the example. The section is about booleans, and how booleans behave in each context, in context of conversions, type equality, and such. It is not about the not operator. 72.152.120.17 (talk) 01:02, 8 March 2011 (UTC)

PS: "Contrary to what you keep repeating, you did not provide an example that clearly demonstrates the behavior of a Boolean operand being automatically converted to number for comparison." How about "alert(true == 1)" ? That looks like a good example to me. You seem to have trouble noting these things. 72.152.120.17 (talk) 01:04, 8 March 2011 (UTC)

Function example code misleading

var obj1 = {a : 1};
var obj2 = {b : 2};
function foo(p) {
  p = obj2; // ignores actual parameter
  p.b = arguments[1];
}
foo(obj1, 3); // Does not affect obj1 at all.  3 is additional parameter
alert(obj1.a + " " + obj2.b); // writes 1 3

This is misleading because obj1 can be modified by the function. It is quite odd (in an explanation) to pass a parameter to a function and then ignore it. Consider:

var obj1 = {a : 1};
var obj2 = {b : 2};
function foo(p) {
 p.a = 7;  // modifies global variable obj1
  p = obj2; // no effect on obj1, ignores actual parameter
  p.b = arguments[1];// modifies global variable obj2
}
foo(obj1, 3); // Does affect obj1.  3 is additional parameter
alert(obj1.a + " " + obj2.b); // writes 7 3

Because the object parameter is passed by reference it can be modified. This is OR for me. I am just learning. But I was surprised that obj1 can be modified in the function, by p.a=7, yet p=obj2 does not affect obj1. This should be explained. QuentinUK (talk) 02:27, 28 June 2011 (UTC)

Some of the primitive data types also provide a set of named values that represent the extents of the type boundaries. These named values are described within the appropriate sections below.

Is this a long winded way of saying "null, Infinity, NaN, true, false"? What other boundary values are there? QuentinUK (talk) 11:49, 21 July 2011 (UTC)

Number.MIN_VALUE and Number.MAX_VALUE come to mind: the global properties Infinity and NaN (same as Number.POSITIVE_INFINITY and Number.NaN, there's also Number.NEGATIVE_INFINITY) are a bit philosophical... they're special values with particular results specified for comparisons/casts/calculations. (I think true, false, and null are keywords as opposed global properties). I would definitely remove the generalization.—Machine Elf ¹⁷³⁵ 01:22, 24 July 2011 (UTC)

These are not mentioned so the initial statement is misleading. Also there is a range of numbers between Number.MAX_VALUE and Number.POSITIVE_INFINITY, "so boundaries" is also misleading. QuentinUK (talk) 03:27, 25 July 2011 (UTC)

Strings

I've seen strings defined as

   var greetings = /Hello World!/

what's going on here, ie how come this is not mentioned in the article. QuentinUK (talk) 12:08, 21 July 2011 (UTC)

It's a regular expression object literal.—Machine Elf ¹⁷³⁵ 01:22, 24 July 2011 (UTC)

Split Boolean

One problem with this article is that you can not read it from start to end. ie In the Boolean section it discusses the == operator and the || and && operators before they and their odd behaviour are mentioned.

   // That the following are different surprised me:-
   alert(2 && true); // true
   alert(true && 2); // 2
   // also
   alert(2==2==1); // true
   alert(1==2==2); // false
   // But if the rules were explained first they wouldn't have.

QuentinUK (talk) 17:39, 21 July 2011 (UTC)

I got tired of reverting an obnoxious IP who didn't understand coercion issues. For whatever reason, they were fixated on the section about the Boolean constructor but should have focused on the sections about the operators... comparison, assignment, conditional, logical... Machine Elf ¹⁷³⁵ 01:22, 24 July 2011 (UTC)

Unlike C, whitespace in JavaScript source can directly impact semantics.

1) In C whitespace is important for pre-processing. 2) In C++ whitespace in needed for nested templates > > otherwise this becomes >> a shift

QuentinUK (talk) 17:20, 21 July 2011 (UTC)

As in "how so"? Offhand, semicolon insertion, escaping line terminators in string literals, stray byte order marks... js doesn't normalize Unicode equivalents, strings are just so-many 16-bit unsigned integers.—Machine Elf ¹⁷³⁵ 01:22, 24 July 2011 (UTC)

It is not unlike C in this respect. So the statement that it is unlike C is incorrect. QuentinUK (talk) 03:18, 25 July 2011 (UTC)

I don't know JavaScript, I saw some code with some lines starting with a semicolon, I wrongly interpreted it as a line comment like the // in C++ because other languages, like several assemblers and Lisp, treat semicolon as a line comment.

I learned from this article that JavaScript has an ambiguous syntax with this respect.

Syntax ambiguities should be a section in the article, although I think that the whole article should be rewritten focusing on the syntax of the language.

Strict equals transitivity

The following

alert(   !0 === Boolean(  !0 ) ===   !!1 === Boolean(    1 ) === true  );
alert(  !!0 === Boolean(   0 ) ===    !1 === Boolean(   !1 ) === false );
alert(  !"" === Boolean( !"" ) === !!"s" === Boolean(  "s" ) === true  );
alert( !!"" === Boolean(  "" ) ===  !"s" === Boolean( !"s" ) === false );

Gives the impression that equality can be chained together. A===B===C being true when they are all equal, this is not the case. QuentinUK (talk) 10:57, 11 August 2011 (UTC)

Variable declaration

In the "Variable" section, shouldn't there be a word about usage of the keyword var? What happens when you use it? What happens when you don't?

Also, the section on semicolons reads like a personal blog and contains a reference to an outside blog. --Tim Sabin (talk) 17:58, 13 April 2012 (UTC)

Assignment Examples -- Primitive Types

The examples for -= and /= (shorthand for non-commutative operations) don't currently allow the reader to infer the order of the operations. If we start with x=3, it isn't clear why the result of x /= 3 is 1. Was it because x was divided by 3, or because 3 was divided by x? For this reason I am changing the numerical values in the example sequence. Evaluist (talk) 22:42, 15 November 2012 (UTC)

Testing for `undefined`

Unless some one sees an issue with it, I will add this to the way to check for the `undefined` special value:

   function isUndefined (o) {
      return ((typeof o) === "undefined");
   }

Seems the way using `typeof` is missing in the document. --Hibou57 (talk) 19:25, 18 July 2013 (UTC)

Doesn't mention ES6's "spread operator": ...

MDN and MSDN both talk of a spread operator, written "..." and it's not covered here or on other places I've been able to find on Wikipedia about JS or ES6. Then again I've been told that even though major JS sources call ... an operator it may not technically be an operator. — Hippietrail (talk) 06:08, 27 January 2016 (UTC)

I took a try at creating a section about the spread/rest operator "...". I placed it in the section on operators, although now that I think about it, it's probably true that it's not an "operator" in the strict sense. It's more like syntactic punctuation, along the same lines as "[]", "{}", commas, and semicolons. In which case, rest parameters should perhaps be moved into the section on functions, and spread syntax should be moved into the section on arrays (and maybe also mentioned in the section on funcions). --2404:130:0:1000:102E:358C:1F00:94A4 (talk) 06:48, 29 September 2016 (UTC)

Maintenance and rating of JavaScript articles

Concerning editing and maintaining JavaScript-related articles...

Collaboration...

If you are interested in collaborating on JavaScript articles or would like to see where you could help, stop by Wikipedia:WikiProject JavaScript and feel free to add your name to the participants list. Both editors and programmers are welcome.

Where to list JavaScript articles

We've found over 300 JavaScript-related articles so far. If you come across any others, please add them to that list.

User scripts

The WikiProject is also taking on the organization of the Wikipedia community's user script support pages. If you are interested in helping to organize information on the user scripts (or are curious about what we are up to), let us know!

If you have need for a user script that does not yet exist, or you have a cool idea for a user script or gadget, you can post it at Wikipedia:User scripts/Requests. And if you are a JavaScript programmer, that's a great place to find tasks if you are bored.

How to report JavaScript articles in need of attention

If you come across a JavaScript article desperately in need of editor attention, and it's beyond your ability to handle, you can add it to our list of JavaScript-related articles that need attention.

Rating JavaScript articles

At the top of the talk page of most every JavaScript-related article is a WikiProject JavaScript template where you can record the quality class and importance of the article. Doing so will help the community track the stage of completion and watch the highest priority articles more closely.

Thank you. The Transhumanist 01:10, 12 April 2017 (UTC)

Comments Please

I thought the commenting on the examples was very good up until the last example in the Function session & several in the Objects section. Without having the ability to set breakpoints to follow the logic, I had trouble understanding what the author wanted to demonstrate.

 I don't know if my sentiment is widespread because I am self-taught and may have missed some implied points along the way.  Otherwise, I thought it was well-done. The Source Whisperer (talk) 03:58, 6 May 2019 (UTC)

With statement listed at Redirects for discussion

An editor has asked for a discussion to address the redirect With statement. Please participate in the redirect discussion if you wish to do so. — Arthur Rubin (talk) 10:56, 19 May 2019 (UTC)

This is not the JavaScript syntax is a very long description of the language

A programming language syntax is a set of grammar rules which produce any correct written program in the given language. i.e. a program that the compiler/interpreter can analyse (parse) to translate.

It doesn't mean that a grammar produces code with no "bugs", vgr. for(i=m; i<n; 0++) is syntactically correct although evidently meaningless because that program never stops. A rule restricting $m<n$ and the appropriate increment which will make i<n false to end the loop, is semantic, not syntactic.

Such rules are usually described by means of BNF grammars or syntax diagrams.

The article may also include a semantic description of each program construct. (Semi-formal of formal if there is one.)

I don't know JavaScript, but I doesn't seem a monster like C++ with about 300 keywords. It seems to be a much smaller one, which can be described in a more short article.

I agree that this article is too long, but the solution is not to fragment it. Instead, should be written, one that meets what the title say JavaScript syntax or one that includes the semantics and rename it to JavaScript syntax and semantics.

The article should start with the description of the atomic elements like a keyword list, legal variable and other user defined names, the syntax of numbers, and whatever plays the role of words in a sentence. Then the rule that describes a program, followed by each construct of a program. Because I don't know JavaScript, I can't say something more correct. Take it as a general guide for the volunteers that accept this mission.

The source of information can be the standard manual of the language if it exist, please so don't expect hundreds of references. Just a list of manuals describing the evolution of the language, because some constructs appeared from the first version, others in later versions. It would be ridiculous to tag such article urging for more references. It is a simple task for an experienced JavaScript programmer with some formal education in IT. Elias (talk) 06:56, 25 December 2019 (UTC)

@Elias:. Thumbing up. I agree the article must be shortened. I also suggest to move examples to a separate one.

[...] The article may also include a semantic description [..] It would be disastrous to the article as specs contain a lot (I mean A LOT) of elaborated IDL definitions for very simple language constructs. I stand for providing simple examples avoiding making article overly academic/specific. AXONOV (talk) ⚑ 08:35, 13 October 2020 (UTC)

Module syntax

Module syntax which is the most basic thing of every JS interpreter is missing. I suggest to make section on how module system works per different implementations like browser/server(e.g. Google Chrome/Node.js). I suggest to avoid making it bloated as to address issue pointed out by Elias. AXONOV (talk) ⚑ 08:35, 13 October 2020 (UTC)