"Weakly" Typed

Wouldn't it be more NPOV to refer to this as "loosely typed" rather than "weakly typed"? After all, lots of people prefer loose typing, and don't think of it as "weak". —Preceding unsigned comment added by 71.243.40.241 (talk) 23:00, 21 March 2008 (UTC)

Not really. Weak typing is a technical term. Other examples: weak reference, weak topology - these are completely neutral terms. --Maian (talk) 15:46, 11 July 2008 (UTC)

Please pardon my ignorance. What exactly does "loosely / weakly typed" mean? Having toyed with it daily (96 days out of 100) for all of ten years, I've found it to be as unforgiving as any other language. Rudimentary? Yes. Loosely typed? Hmmm. "A" does not mean "a"

Once something is declared, it's there for good. The only way to change it is to overwrite it, shut it down or in worst case, a memory overflow. The links above don't apply.

One has to both parse string info and string parsed info for things to work, am I right? If it was loosely typed by my definition, those looping evals I struggled with throughout the years should have been a breeze. Regular expressions would be mastered by everyone. Maybe it's "loosely / weakly typed" in WYSIWYG editing applications. I don't know. Never used any of those applications to the extent other than to justify they're crap and restrictive. Or is it "loosely / weakly typed" because browser defaults don't require certain specifications in command call ups? If someone can, please tell me how javascript is "loosely typed or weakly typed." You have my permission to take a baseball bat to my cranium, repeatedly if necessary.

I've read through this article and have found it is very good, even by my unhealthy Freudian standards. Everyone who has contributed deserves commendation. Sorry to be so dumb, but it is the most glaring statement to me. Kentholke (talk) 04:20, 11 March 2009 (UTC)

Unfortunately, "weakly typed" is one of those terms that is overused to the point that its definition is hardly stable. As far as I understand it, it just means that the language is far more "forgiving" with types than so-called "strongly typed" languages (like Java), where "forgiving" is open to interpretation. In JS's context, there's no static type checking, numbers and strings can sometimes (and confusingly) be interchanged (e.g. x[1] == x['1'], 1 == '1'), all values have implicit boolean values, it has dynamic typing, and objects can be augmented in a way that doesn't change their "nominal type" (changes its "structural type" instead). This is why JS has all these various ways to test the "type" of an object. --Maian (talk) 08:08, 12 March 2009 (UTC)

I think the basic definition is a language that variables do not to have their data type defined at compile time rather then at runtime by the compiler. I also think that loose typing and weak typing are interchangeable as mentioned by the article given above. Mmick66 (talk) 15:31, 30 December 2011 (UTC)

The thing which is of utmost importance, though, is that, while x[1] == x['1'], and 1 == '1', x[1] === x['1'] yet 1 !== '1'. In any case, at least according to Wikipedia, weak typing and [typing] are synonymous. (Though, I must disagree with the comments on the talk page there; dynamic typing is not the same thing as no typing.) brianfreud 02:32, 2 February 2012 (UTC) — Preceding unsigned comment added by Brianfreud (talk • contribs)

Merger proposal

I think it's a good idea to merge this page with JavaScript syntax. This is because Wikipedia is not an instruction manual. Wikibooks already has a book about JavaScript, and there is no reason to duplicate content. Nate879 (talk) 02:10, 27 August 2008 (UTC)

I'm pretty neutral to this idea. I'm not sure what should be moved from the JavaScript syntax to this article without making this article bloated. Maybe, we should just move all the information that JavaScript syntax has to the wikibook, if it's not already there. Is it possible to have JavaScript syntax redirect to the JavaScript wikibook? --Maian (talk) 01:22, 1 September 2008 (UTC)

The wikibook version is too "web-centric", and spends more effort on how javascript is embedded within other environments. The wikipedia article is independent, pristine Javascript. Like Goldilocks, I find this treatment "just right".

You point out that Wikipedia is not an instruction manual. I don't believe this article satisfies the definitions of a how-to manual that you cite. For example, the article on the International Phonetic Alphabet gives a full exposition of the the structure of IPA - to my eye it is very similar to the Javascript article in question. I think for something that truly permeates the entire web, an extensive declarative exposition (as distinct from the history and politics of) is certainly in the purview of Wikipedia. I used my old Funk and Wagnalls (now Encarta) as a refresher for many a mathematical concept. For example, look at the Encarta treatment of Calculus. It might be from the terrible Microsoft empire - put it reflects what Funk and Wagnalls did for decades. Clearly it qualifies as something an encyclopedia does! The main body of the article is a simple exposition of the topic itself - the Leibniz versus Newton controversy or any of the politics of Calculus is reserved for a brief mention in the final section. I find the wikipedia Javascript syntax article to be very equivalent. --BirdieGalyan (talk) 00:40, 3 September 2008 (UTC)

js syntax article is long enough to be on its own i think. —Preceding unsigned comment added by 69.125.25.190 (talk) 15:51, 14 September 2008 (UTC)

I do agree that some sections are applicable for merging with JavaScript syntax. However, this also talks about other things which are generally irrelevant to the syntax of JavaScript. Perhaps some of the information could be merged while others remain on this page on its own. --E0alpha (19:03, 25 September 2008)

The JavaScript syntax page is alright on it's own. This page is fine without it. Searching (JavaScript syntax) in the browser should lead us there. —Preceding unsigned comment added by 202.156.9.4 (talk) 07:56, 26 September 2008 (UTC)

There is absolutely no need for a "JavaScript syntax" page, especially not when there's a link to MDC in the external links section. --Execvator (talk) 10:49, 26 September 2008 (UTC)

The two pages should remain separate, one is more about the history of JavaScript and the other a brief summary of its use. The syntax page omits some of the more technical features (such as closures and the this keyword) but that is OK. Also, it should make clear the distinction between the language (which is actually ECMAScript Language or ECMA-262) and JavaScript, which is both the official name of Netscape’s implementation and the colloquial name for all other implementations in browsers.--61.88.57.1 (talk) 00:06, 10 October 2008 (UTC)

I personally think this page should remain how it is, it's got some great information in it. Those who aren't actually programmers might want to learn about the history of the languages, not the actual syntax of it. RuneScapez (talk) 19:47, 17 October 2008 (UTC)

I believe JavaScript and JavaScript syntax should be merged. If you're describing JavaScript, part of your description should include the language's syntax. JavaScript syntax doesn't exist on its own; it's an integral part of JavaScript, and has no life outside of JavaScript. Yes, there's lots of good info in both articles, and the total is quite long for a single article, but to me this says "trim it down" rather than "split it up". Yes, the current Wikibooks article is very web-centric, and not as thorough, but that doesn't mean that Wikipedia needs to do what should be Wikibooks' job. -- Dan Griscom (talk) 16:50, 3 November 2008 (UTC)

Oppose merge: Both articles have substantial content and both seem to have encyclopedic merit. BirdieGalyan's points above state the point well. What would really be useful is if the content could be united under an article series. dr.ef.tymac (talk) 12:23, 18 November 2008 (UTC)

Oppose merge, there is no need for these articles to be more confusing. Unless you have a problem with two separate articles, it's perfectly fine the way it is. 173.183.79.81 (talk) 00:59, 16 March 2011 (UTC)

How about we try and bring the two pages closer together... before even we consider merging them. Right now, the syntax section of the main article is nothing but programming examples and does not do its name justice. I will try and tidy it up a little bit... Mmick66 (talk) 17:13, 29 December 2011 (UTC)

Object-oriented programming section

I find this section to be both misleading and redundant. It's misleading, because it says "Object-oriented JavaScript is still in its infancy" when JavaScript is already OOP at its core. While it's not the same blend of OOP featured in languages like Java, it's still OOP. In fact, if you look at the OOP page, prototype-based programming is a subcategory of OOP. It's redundant, because the Features section already explains how JavaScript is OOP, and there's already an article on JavaScript frameworks, the majority of which include OOP features. In fact, it may violate NPOV to specifically mention the objx.googlecode.com one. Pending your response, I'll remove this section in a couple days for the above reasons. --Maian (talk) 02:19, 11 February 2009 (UTC)

I was also quite astonished by this header and agree with Maian in general. Meanwhile with some wording changed (including the header) and some meanings revised this section might be retained, if we assume its meaning as a statement that JavaScript OOP facilities were underestimated and OOP practice was quite poor during a long period before the boom of AJAX... I tend to agree that only recently the full programming power and potential of JavaScript started being discovered by "programming folks masses", myself included :) --S-n-ushakov (talk) 00:16, 12 February 2009 (UTC)

I removed this section a while ago... --Maian (talk) 13:09, 17 March 2009 (UTC)

I added a new section on OOP in Javascript and did my best to clarify some, quite confusing, concepts. Please let me know what you think.Mmick66 (talk) 15:38, 30 December 2011 (UTC)

functions as object constructors

Some functions can be used as constructors. In contrast, the article incorrectly states "Functions double as object constructors along with their typical role." This is is wrong, and explained in ECMA-262, s 15.

None of the built-in functions described in this clause that are not constructors shall implement the Construct internal method unless otherwise specified in the description of a particular function.

This is further realized in the internal algorithm steps for Construct [1].

If constructor does not implement the Construct internal method, throw a TypeError exception.

Instead, the article might mention that "Some functions can be used as constructors," or perhaps "Some functions, such as user-defined functions and built-in constructors" can be used as constructors. 67.169.93.56 (talk) 20:36, 9 September 2012 (UTC)Xkit

Influenced by... languages, dubious

I have to question the validity of the "Influenced by" section. Javascript influenced by Python and Java? The three languages have nothing alike, so I fail to see where the influence comes from. Any references/citations to back this up? 59.167.188.168 (talk) 05:15, 7 December 2010 (UTC)

-- For the Java part, I might mention the 5th edition of the ECMAScript specification, published in December 2009: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf. In particular, see section 4.2, the main overview, where the document notes that "ECMAScript syntax intentionally resembles Java syntax". I see that this is a fairly active article, so I won't make any modifications here myself, but I might suggest indicating that JavaScript's syntax is based on Java's rather than C's in the main introduction. I understand, however, that this may be a stylistic choice since Java uses C-like syntax, and an effort appears to be taken to emphasize the important distinction between Java and JavaScript--but the change might make the article more informative as to the origins of the language name. Just some thoughts. --Gillespie09 (talk) 21:37, 3 January 2011 (UTC)

Just search for Python in the article to see how it how it influenced later versions of JavaScript. Undecided on whether it's appropriate to exclude C - generally, when discussing the syntax, we say it's a "C family syntax" rather than a "Java family syntax", but the C syntax was inherited thru the Java influence. Maian (talk) 09:39, 4 February 2011 (UTC)

Ah, forgot this quote (in this very Talk page!): When I created JS in May 1995 (in about ten days for the core language implementation; the rest of that year was consumed by the DOM and browser embedding work), my influences were awk, C, HyperTalk, and Self, combined with management orders to "make it look like Java." Maian (talk) 09:44, 4 February 2011 (UTC)

Alert / Prompt in Examples

Neither alert nor prompt functions feature in the language spec ECMA262v5 so perhaps the 'basic' examples that include them should be removed, rewritten, or include explanation of where and when these additional capabilities are available. --2.125.241.212 (talk) 09:05, 11 April 2011 (UTC)

Wonder if this article's really a good place for long examples anyway. You're going to come here if you just don't know what JavaScript *is* or if you want to get to more specific resources (on, e.g., security, performance, compatibility...) but you won't *learn* JS from Wikipedia, so demoing lots of features in an example doesn't make sense. I think of it in terms of how I'd describe JavaScript to someone who doesn't know much about it, or where I'd send people with general questions.75.24.106.187 (talk) 21:10, 24 May 2011 (UTC)

its good — Preceding unsigned comment added by 61.245.172.57 (talk) 14:31, 31 May 2011 (UTC)

Removed and condensed some examples. Isolated web browser-specific stuff in single function in the "advanced" example. Maian (talk) 10:01, 27 August 2011 (UTC)

"considered functional"?

Saying JavaScript is considered functional because it has closures is pretty disingenuous... Just about every modern programming language that has lexical scope has closures or some form of them aside from C. Even in Java, local classes capture anything final in the surrounding lexical scope, and if you're invoking anything that takes in a function as an argument, it will be wrapped in an interface, so all you do is pass in an anonymous instantiation of that interfaces; thus it's basically exactly the same as closures in Haskell et al. — Preceding unsigned comment added by 207.35.173.122 (talk) 21:57, 7 June 2011 (UTC)

"Functional" is a programming paradigm. It's comparatively easy to program in a functional style in JS than in Java, as you mentioned. The fact that most modern programming languages support this paradigm does not mean take away the fact that JS can be programmed in this way. Compare with the ubiquitous imperative programming style. Now "pure functional" programming is a different story, which few languages support. Maian (talk) 09:59, 27 August 2011 (UTC)

Opera

The article indicated that Opera versions 6.0-11.50 supports no later JavaScript than version 1.5. I have Opera 11.50 and I can confirm that 11.50 does support JavaScript 1.8. I have edited the Versions section in the article according to this evidence. Urbanus Secundus (talk) 03:05, 22 July 2011 (UTC)

JavaScript and ECMAScript

This article states, several times, that JavaScript is an implementation of ECMAScript. This seems wrong for several reasons:

• the term JavaScript refers to a language, not an implementation of a language
• there are quite a few different implementations of JavaScript

It would be better to write that JavaScript refers to a language that exists in various dialacts and versions, has varioyus implementations, and has standardized versions known as ECMAScript. Rp (talk) 13:30, 6 September 2011 (UTC)

Recent Facebook attack using JavaScript

Would that warrant a mention in the article? 67.233.229.89 (talk) 02:44, 16 November 2011 (UTC)

Orientation for non-technical users; J* error/msg

For non-technical browser users (here because you want an objective explanation of an error),
Java is not quite JavaScript (MozillaZine KB) nor Jscript, but all are used or required by programmers & vendors to provide enhanced user interfaces to dynamic websites.
Your web browser will need to have the appropriate support software installed and enabled, to display the corresponding effects (certain pictures, fill-in forms, games, adverts, etc.). Enabling might be simply the browser settings, or also support software like the NoScript(Firefox > tools > add-on). Inconsequential technical details follow.

Java is a programming language used to create stand-alone software applications (programs, especially games). Java programs can also be embedded in web pages, as ‘applets’. Java applications and applets require the Java Run-time Environment (RTE) to be installed on your system.

JavaScript is a programming language also used in writing Mozilla products like Firefox. It is usually a small series of commands that are often embedded in a web page to do things like create pop-up menus or windows, and validate form data. Support for JavaScript is built into XUL-based applications. JavaScript uses many names and naming conventions from Java, but has semantics & design principles from C, Self and Scheme.

JScript is the intentionally incompatible Microsoft version for some (Ms) sites.
--Wikidity (talk) 20:13, 26 December 2011 (UTC)

Original research

I'm concerned with the recent edits due to the original research, editorializing, and instructive pseudo-code. I don't mean to be rude or anything, but it's clear you're not using reliable sources.—Machine Elf ¹⁷³⁵ 13:31, 31 December 2011 (UTC)

I just added references to the sources I used and examples. Most are from solid O'Reilly books and D. Crockford's web pages so they should be ok. If you find it satisfactory we can remove the "original research" warning Mmick66 (talk) 15:30, 31 December 2011 (UTC)

In one case, I'm not able to verify the page number you've cited (I'll tag that with vn). The OR tag to solicit help from other users as well…

Regarding the pseudo-script you keep re-adding, you've misunderstood Crockford. Also, you shouldn't use a name from real examples: someone might run an executable pseudo-script… I doubt it should be included in this article; it's confusing and distracting. But rather than remove it, I'll see if can correct the basic understanding, at least.

It seems you don't re-add things once you do understand that you were wrong about something, but you'd be well advised to collaborate by not re-adding at all, even if you don't yet see a mistake, (perhaps requesting clarification instead). Anyway, in the cases where I did take the time to contribute counter-examples, I'll assume that's why you've deleted them. It's a far cry from adequate and your time would be better spent summarizing what's in the JavaScript syntax article, (see WP:SUMMARY). Please don't feel compelled to contribute more advanced material for the sake of completeness. Happy new year.—Machine Elf ¹⁷³⁵ 00:47, 1 January 2012 (UTC)

Thanks, I did not delete your sections (code), I moved them from the 'Functions" section to the 'OOP' section because I think that they belong there and merged them with my examples. Since a lot has been written please explain the point where my error is. I think you are referring to the this keyword and the fact that it does not point to the prototype but rather the newly created instance. You are absolutely correct with that and I have included your edit in more than one sections. Please let me know if you have found further mistakes. Also, I do not understand the remark about the pseudocode. I guess you are refering to this.prototype = {constructor: this}; . I understand that you mean that it should explicitely be mentioned that it is pseudocode rather than real code... You are right, please let me know how you suggest we procede. Mmick66 (talk) 16:00, 1 January 2012 (UTC)

Yes, you did delete the samples I added. No, you did not just “move” them or “merge” them. As I've been trying to inform you, less bluntly, you don't have a firm enough grasp on Javascript to make the edits you've been attempting. Furthermore, it's clear from your response that you don't realize how substantial and numerous your errors “really” are. And egregious too, you go quite far out of your way at times, repeating some bit of WP:OR you fancy: calling a clearly named function “anonymous”, for example… You'll be astonished once you figure out how very little that pseudocode is intended to demonstrate. The warning was for your benefit, BTW. Perhaps you can't be bothered to test at all, then again maybe, you were running your pseudocode and that screwed up so many of your examples. It's quite beside the point. Even when I spelled it out for you, exactly what the pseudocode was intended to demonstrate, you're just couldn't see it. It speaks volumes that your reaction—despite being asked not to—was a prolix rewrite, changing it back to the same conspicuous error. And don't try to blame it on Crockford; he makes himself clear, it fails WP:V. But why do you cite mistakes that you didn't even write ?!? i.e, confusing the increment and bitwise operators and misattributing the former's problems to the latter. I don't know why, but you've sighted the same page in several places, however, it's not available on Amazon or Google Books. You should probably verify that, don't you think?

Well, this has gone a little over five minutes… but it's true, a lot has been written. Maybe you'd have done better to have reviewed it?—Machine Elf ¹⁷³⁵ 00:53, 2 January 2012 (UTC)

First off... The only piece of pseudocode, to my understanding at least, is the one at the end of the 'Functions' section referring to the this.prototype = {constructor: this}. It is very clear that it is pseudocode since you, very correctly, wrote it down with a link AND a warning! Why would anyone try and run it ??? I do not see how this line of code messes up with any other example so please clarify. I dont know what you mean by "how little the code is supposed to demonstrate" but it is important since there are very few Javascript resources that touch upon this very important issue of prototypical inheritance and D, Crockford, I believe does a good job demonstrating how the code "could look like". The pseudocode aspect of the code is very clear. Plus... it will not BLOW up your machine if you try and run it like I have the feeling it will from your writing. Of course I ran the rest of the code I wrote and of coure it worked so if you have another opinion please clarify. Now, the sections I deleted where merged, why would I delete some good content ??? They where merged with the OOP section. The code you wrote was just not as related to Functions as much as it was to OOP and inheritance what can I do?... If you think I have omitted something important please put it back or give me a more concrete example. Now... I have a good enough grasp of Javascript to have identified many errors in the older version of the article. The stuff about Object Orientation was just not good and very misleading. Alos, where is the 'anonymous' function you talk about. The 3 instances I see are clearly anonymous as they are defined as function() {}, so where is the problem? Mmick66 (talk) 08:19, 2 January 2012 (UTC)

I didn't say it would “BLOW up your machine if you try and run it” but we wouldn't call it pseudo anything if ‘SomeFunction’ came out hunky dory, now would we? I didn't claim that you did run it, just that one excuse for the apparent lack of testing might have been running pseudocode accidentally. How do you explain so many errors and omissions if, in your “opinion”, you tested? By denial? How tedious.[2][3][4]

“…it is important since there are very few Javascript resources that touch upon this very important issue of prototypical inheritance and D, Crockford, I believe does a good job demonstrating how the code "could look like"…” What Javascript WP:RS doesn't touch upon prototypical inheritance? No, it couldn't look like that, nor did Crockford say it could. That pseudocode was only meant to explain that constructor is “redundant”. You leave out everything else… I'm sorry to have to tell you, but you're right about one thing: it is very clear what Crockford's pseudocode does and does not do.

And give it a rest, I should provide what? A counter-example for you? Showing that you “merged” one line? It was a mistake to indulge your examples in the first place. Better I don't make it twice. I'm not saying there's no contribution you can make to this article. But at the rate you're going, if you're going to argue that you're entirely competent at every level, and fiddle with everything again and again when people clean up after you, then… you tell me. Speaking of pre-existing errors, mistakenly citing them is sure no help. Are you going to address that verification needed tag or no?

Per your request, §Functions as constructors: (emphasis added)

function Person() {
   this.name = name;
}
var person = new Person("Mike"); // instantiating through the constructor
alert(person.name) // alerts "Mike";

function Person() {
   this.prototype = {constructor: this};
}

If you prefer, I'll grant it's not even wrong to say “An anonymous object is created”. Only function objects are said to be named or anonymous but, inexplicably, you weren't referring to the function under discussion, were you; which just so happened to be named. Of course, in broader terms, an object may be referred to by various names; if not, we call it garbage.

While not exhaustive, as I noted, it merely shows one of the “names” contained by prototype is constructor, which refers to the function (Crockford's point being that it's “redundant”). Assignment of an object literal certainly fails to illustrate whatever quasi-mystical genesis you seem intent to emphasize, yet again. Or perhaps you imagine that assignment of an object literal poses a nominal paradox? Née “anonymous”? At any rate, it makes a trivial point about how functions are created, including those used as constructors. But it illustrates neither how constructors create objects, nor anything else about “prototypical inheritance” (except perhaps that object literals inherit from object).—Machine Elf ¹⁷³⁵ 21:40, 2 January 2012 (UTC)

Sorry for misunderstanding your maybe in bold!... for implying that most of my code does not run. I still do not see the connection with this one line of pseudocode that you took the time to explain me what it means. You dont need to grand me anything about the 'anonymous' functions since the function I was referring to (the one defined as var x = function() {};) simply is anonymous, as is very clearly stated D.C's book^[2]. And, NO, Crockford did not want to just illustrate that is redundant as you can see by simply reading page 47 of the same book. He wants to show how prototypical inheritance works (as he is stating). Now.. as per my request what??? I do not understand how the code you quote shows anything... Literal assignment is yes quite unique as compared with modern OOP languages and the FUNCTION that takes part in the assignment is anonymous... And if it is a trivial matter then why do we still have an even more trivial block of code with random examples that could be moved in the proper (syntax) article to which you disagree? In any case, you seem to prefer the old article which in my opinion showed next to nothing about the real structure of the language and contained many misleading statements... so I reverted it back to where it was and I will leave it thereMmick66 (talk) 00:00, 3 January 2012 (UTC)

• Generally, the problem with your code was that it doesn't produce the result you claimed it would.
• I've never mentioned var x = function() {}; have I?
• I should re-read page 47 huh? Didn't I provide that page number for you? Wouldn't it be better if you re-read Crockford until it dawns on you? Think “function constructor” rather than “constructor function”… As you've deleted it, I'll provide that info once again, and include page 47 here for your convenience:

Crockford, D. (2008). JavaScript: The Good Parts. O'Reilly. p. 47. ISBN 9780596517748. 

    this.prototype = {constructor: this};

Function.method('new', function() {
 
// Create a new object that inherits from the 
// constructor's prototype
 
    var that = Object.create(this.prototype);
 
// Invoke the constructor, binding -this- to
// the new object.
 
    var other = this.apply(that, arguments);
 
// If its return value isn't an object,
// substitute the new object.
 
    return (typeof other === 'object' && other) || that;
});

var Mammal = function (name) P
    this.name = name;
};
 
Mammal.prototype.get_name = function () {
    return this.name;
};

• “I do not understand how the code you quote shows anything... Literal assignment is yes quite unique as compared with modern OOP languages and the FUNCTION that takes part in the assignment is anonymous...” Seriously? You think function Person() {...} is anonymous when assigned to the constructor? Did you check Person.prototype.constructor.name? (That's a rhetorical question, BTW).
• So Python, C sharp, etc. etc. aren't modern OOP languages?
• Why do we still have trivial examples? Or rather, why do we still have blocks of code you didn't write?
• I'm to blame huh? You didn't have a hissy fit or nothing… Well, I can't stop you from doing what you think I prefer. You certainly haven't made it a habit. I don't have time to fix it right now, but I see mine aren't the only contributions you deleted along with your own.—Machine Elf ¹⁷³⁵ 02:20, 3 January 2012 (UTC)

• Are you mentally retarded?! You said that DC's point was to show that the constructor property was redundant which is barely mentioned in the page you showed me?! I said that he wanted to show something important about the prototypal nature of Javascript which he clearly DOES. So you might want to re-read what YOU just wrote!
• The ONLY example I copied from DC was this one with the constructor so I cannot see how you can blame me for that. The ony that I DID copy, I copied correctly and referenced fully so I cant see the problem there either
• As I ve said many times what I had INITIALLY deleted from your stuff was merged with mine as it only referred to the this keyword
• I never meant that the Person function was anonymous... If it was not clear what I meant you could clarify it instead of making assumptions about my knowledge.
• We are wasting our time since it seems you liked the article as it was... Let's leave it at that. Sorry if I deleted a few lines from your "work" that where only added in mine after spending 3 days contributing. Hope you can do better Mmick66 (talk) 07:35, 3 January 2012 (UTC)

Yes, you've ended the discussion. I'll remind you there's a policy against personal attacks.—Machine Elf ¹⁷³⁵ 08:28, 3 January 2012 (UTC)

Remove the Syntax and Semantics examples?

I believe that the 'Syntax and semantics' section is the weakest part of the article. It does not do its name justice since it does not list the keywords and reserved words of the language but rather presents the reader with general examples. It also has a huge block of code with random examples that I believe are a) included in the separate Javascript Syntax article (where I think they belong) and b) best shown in their separate sections such as 'Functions', 'OOP', 'Security' etc. Opinions? Mmick66 (talk) 16:05, 1 January 2012 (UTC)

No, the new sections are the problem.—Machine Elf ¹⁷³⁵ 00:55, 2 January 2012 (UTC)

Delete the whole thing if you want. If you truly believe that the article was of more value before than it is now please be my guest.Mmick66 (talk) 08:20, 2 January 2012 (UTC)

RE: JavaScript and Java

There is a great quote in a JS book by Christian Heinelmann of Mozilla saying "Java and javascript are as alike as car and carpet, that is to say not at all" 94.168.179.213 (talk) 12:17, 1 March 2012 (UTC)

General Purpose

With the advent of node.js, Javascript is now used as a General-purpose programming language, like C or Java. Node.js powered JavaScript has now become on of the standard build tools for web projects. Device drivers are being made in JS, see here. Web Application development of course. Now also for Mobile and Desktop with Titanium SDKs and PhoneGap. Further, it also used as a plugin language for many popular Desktop software like Adobe Photoshop, Adobe Dreamweaver etc. Used for Google Script API for remote processes to Google Servers and of course as a complete HTTP Server [5]. --Gaurav21r (talk) 19:20, 24 April 2012 (UTC)

(1) General-purpose use of JS remains fairly niche; the plugin uses are covered under scripting (2) Arguably it's ECMAScript that's being used. --Cybercobra (talk) 00:37, 25 April 2012 (UTC)

Isn't much of it (where "it" is the "general purpose" use, through a wrapper like WSH) actually JScript, rather than JavaScript or ECMASCript? Andy Dingley (talk) 01:03, 25 April 2012 (UTC)

I just noticed the article didn't even mention the history of server-side JavaScript, originally introduced by Netscape, apparently in 1994. Fixed that. Rp (talk) 10:27, 25 April 2012 (UTC)

(1) I really think it should be General Purpose. Check out the build process of some tools. They are moving away from using Java based programs like Apache Ant. Mozilla's Rhino (JavaScript engine) and Node.js based solutions are being used in all the latest packages. We must also remember Rhino has been around since 1997 and Node.js since 2009. Its no longer a niche but is becoming a standard. Also, we can't deny that the language can be used for this purpose, even if you feel its a niche. A language such as CSS can never be used for General Purpose Programming because of the nature of its syntax. Therefore we have to provide the info to the end user that one can use JavaScript for this purpose. --59.178.198.60 (talk) 04:13, 26 April 2012 (UTC)

Reason cited for lack of adoption

The passage that cites Crockford is particularly weak. The problems plaguing JavaScript in 1998 hampering further adaption were not imaginary, but real: Netscape's and Microsoft's competition and rapid development model prevented any meaningful level of compatibility, both between their products and from one version to the next; furthermore, the nature of the language and lack of tool support made any form of organised development difficult. Basically, whatever feature of JavaScript you'd use might break in someone else's browser or server, or after the next upgrade of your own. Additional concerns were performance and security. A few years later, after the dust had settled, the average internet connection and computer had become much faster, security was wider understood, free tooling appeared such as JSLint, and frameworks such as jQuery emerged to fix incompatibilities in a systematic fashion, JavaScript started to gain popularity again. AJAX was enabled by these developments, it is not what caused them! Rp (talk) 10:43, 25 April 2012 (UTC)

disingenuous

can someone please tell me what that means? thanks Abbey1997 811-a (talk) 03:12, 24 May 2012 (UTC)

This is from Wiktionary, our free dictionary sister project:

1. Not noble; unbecoming true honor or dignity; mean; unworthy; fake or deceptive.
2. Not ingenuous; not frank or open; uncandid; unworthily or meanly artful.
3. Assuming a pose of naivete to make a point or for deception.

My computer dictionary says, "not candid or sincere, typically by pretending that one knows less about something than one really does."

Hope this helps! David¹²¹⁷ 03:21, 24 May 2012 (UTC)

thanks Abbey1997 811-a (talk) 03:24, 24 May 2012 (UTC)

You're very welcome. Happy editing! David¹²¹⁷ 03:31, 24 May 2012 (UTC)

"Intermediate" language?

I think this is the wrong term. As someone who works on a Java-to-JavaScript compiler, I wouldn't call JavaScript an "intermediate" language just because a compiler outputs it. The output of the compiler is the target language.

On the other hand, in the Closure compiler, each optimization pass translates from JavaScript ast to JavaScript ast, so there it is really used as an intermediate language. — Preceding unsigned comment added by 76.254.13.132 (talk) 20:16, 13 July 2012 (UTC)

Robert Cailliau Quote

Why put in a (ridiculing) quote from Robert Cailliau, a person seemingly unrelated to javascript, its creation and development. That is like quoting Richard Stallman in an article about Windows 95. — Preceding unsigned comment added by 85.177.150.231 (talk) 19:35, 29 July 2012 (UTC)

Incorrect info on Server-side javascript.

It says that Netscape Enterprise Server was released in 1994 but it also insinuates that javascript was released with the 1994 version. I believe it wasn't released with javascript until version 2.0 of Netscape Enterprise Server.

Can you find a reference to back this up? If so we can use it per WP:V, and so it will be very valuable. Thank you for your contribution. --Nigelj (talk) 20:52, 8 August 2012 (UTC)

Lede too jargony

Having just directed somebody here for information, I glanced for the first time at this article, and was appalled by how unreadable it is for the ordinary reader -- even the first sentence will be incomprehensible to 99% of the world. The two things that every reader ought to be able to grasp are (1) JS is widely used to set up fancy web pages, and (2) it is only loosely related to Java. I would probably be willing to do a little work here if it doesn't involve me in edit wars. Any reactions? Looie496 (talk) 22:51, 22 May 2012 (UTC)

    i noticed that to.  — Preceding unsigned comment added by Abbey1997 811-a (talk • contribs) 03:11, 24 May 2012 (UTC) 

I agree. it looks like someone trying to show how smart they are instead of explaining it so that a regular person could understand it. — Preceding unsigned comment added by 50.137.91.21 (talk) 15:39, 30 October 2012 (UTC)

Totally agree. I didn't understand most of it. Will someone please help? Mnnlaxer (talk) 06:33, 12 January 2013 (UTC)

Added an example

I've added an example to the Simple Examples section (along with a supporting reference). Hope it's fine. Abody97 (talk) 14:51, 22 December 2012 (UTC)

No longer a 'client-side' language

The introductory sentence of this article refers to JavaScript as a 'client-side scripting language'. This designation is increasingly inaccurate as server-side JavaScript technologies (e.g. node.js) gain popularity. I recommend this section be edited to reflect this new reality. — Preceding unsigned comment added by 72.87.239.18 (talk) 23:07, 1 February 2013 (UTC)

This seems to be there as a result of a slow-motion mini edit war that's been masked by other vandalism and reversions during January.

• The longer term wording is "JavaScript (sometimes abbreviated as JS) is a scripting language commonly implemented as part of a web browser in order to create enhanced user interfaces and dynamic websites."
• This was changed to say "JavaScript (sometimes abbreviated as JS) is an open source client-side scripting language..." by this edit by Kkm010 (talk · contribs)
• It was changed to say "JavaScript (JS) is an open source programming language..." by 97.88.147.176 (talk · contribs) in this edit
• It was changed back to "JavaScript (JS) is an open source client-side scripting language..." by Kkm010 in this edit.

Personally, I prefer the longer term wording. JavaScript is now used in serious software development, but it is still a scripting language in that it is not, to my knowledge, usually compiled, always interpreted. It is definitely not limited to client side web browser scripting and that should never have been added to the first sentence in that way. I think it's still fair to say that it is 'commonly implemented as part of a web browser in order to create enhanced user interfaces and dynamic websites', and that should be part of the sentence, whatever else it is used for. I will change the opening sentence accordingly. --Nigelj (talk) 23:30, 1 February 2013 (UTC)

Well, I tried to rewrite the opening lines based on all of the above, but in the end common sense got the better of me, and I decided to use... a reliable source! If you want to know what JavaScript is, you couldn't do better than to look up the opening lines of Flanagan JavaScript: The Definitive Guide. So that's what I did. --Nigelj (talk) 00:00, 2 February 2013 (UTC)

IO functions

I don't agree with "There is no built-in I/O functionality in JavaScript; the runtime environment provides that". JavaScript is normally tied to use with an output device. Is this a semantic misapplication made through cross reference with terminology for activities in other programming languages? It is written as though it is the obvious technical terminology.

However, if the reader follows to I/O, it has no (computer-science) disambiguation of what a programmer might be referring to. Input/output (C++) is probably what the contributor is referring to.

In regular terms, JavaScript has an equivalent to BASIC's print: document.write("Hello World on my display"). Additionally, the developer (or program) can call scripts to affect outputs in real-time. Sending code to the console is not essential for script execution. Overall, JavaScript standards are tied to Internet communication involving extensive I/O. Brett Johnston (talk) 03:49, 19 November 2012 (UTC)

I have to disagree. JavaScript, on its own, is incapable of interacting with the user. What that means is that there are no special static constructs that define a method of interaction in the language. You mentioned document.write, which is a method that is related to the DOM, not JavaScript itself (an important distinguishing, in my opinion). One can similarly argue that alert and prompt provide a two-way means of interaction, but one needs to consider JavaScript platforms that are not a web-browser (Node.JS being the most obvious example). Also, I added a quote (referenced) from the ECMAScript 5.1 specification which specifically says that ECMAScript itself doesn't have a defined means of I/O (you can see it in the article in the Simple examples section).

I'm happy to discuss this if you have reasons to believe otherwise. Abody97 (talk) 19:45, 22 December 2012 (UTC)

Of course document.write() is not part of JavaScript, just an example of accessing an object (document) and one of its methods (write()). The same applies to window.alert() etc. The questions are, where do these objects - document, window, etc - come from? and what would JavaScript's IO capability be without them? They come from the host application, which is often a browser, but does not have to be. For example, look at [6] where users of javax.script are shown how to expose an object (in that case a file) from the host (Java) system into the object space that the script (e.g. JavaScript) engine will inhabit. So in that example, scripts written to run in that environment should be able to read and write from and to that file for their IO. Secondly, what would JavaScript be able to do in terms of IO without any such binding from the host system? The most succinct answer I can find quickly is here: "ScriptContexts also expose Readers and Writers that can be used by the ScriptEngines for input and output." In other words, unless suitable IO objects are set for a JavaScript engine by its host environment, there are no IO capabilities inherent in the language itself. Indeed the article says (with ref): "There is no built-in I/O functionality in JavaScript; the runtime environment provides that. The ECMAScript specification in edition 5.1 mentions [this]^[3]" --Nigelj (talk) 22:20, 22 December 2012 (UTC) your mama† — Preceding unsigned comment added by 99.249.206.15 (talk) 22:36, 2 June 2013 (UTC)

"Vendor-specific extensions"

The sentences at the beginning of this section don't match the items that are listed within it.

JavaScript is officially managed by Mozilla Foundation, and new language features are added periodically. However, only some non-Mozilla JavaScript engines support these new features:

I think the logic in the second sentence is inverted; from reading through the list of features below it, I know that at least the following are supported by Mozilla's JavaScript, and often not by other engines:

• property getter and setter functions ^{[4] [5]}
• proper block scope via the let keyword ^[6]
• generators and iterators ^[7]

— Preceding unsigned comment added by Whitelynx (talk • contribs)

The first sentence implies that Mozilla JavaScript engines should support all these features. The second sentence means: "As for non-Mozilla JavaScript engines, only some of them support these new features." To avoid confusion, I have deleted the precision "non-Mozilla" from the sentence. —C.P. (talk) 15:39, 16 March 2013 (UTC)

1994 or 1995?

The article gives a September 1995 release date for client-side js, but then says that server-side javascript was released in 1994 [i]after[/i] the browser version. I don't know enough about this to correct it. — Preceding unsigned comment added by 64.129.32.18 (talk) 15:00, 16 April 2013 (UTC)

separate _critique_ section could be added based on: http://johnkpaul.github.io/presentations/empirejs/javascript-bad-parts/ I have been looking for the things mentioned in the above presentation, but could not find it in this article (note that the critique is just about the language and not the browser/web/DOM/etc) — Preceding unsigned comment added by 46.249.151.28 (talk) 10:50, 25 May 2013 (UTC)

Saying "Weakly typed" is ambiguous and subjective

I think calling a language "weakly typed" or "strongly typed" is a poor and ambiguous description. As the Strong and weak typing article describes, these are very subjective terms and mostly used when criticizing or advocating a particular language. I think the description should simply say JavaScript has dynamic and duck typing. Also note that the Ruby and Python articles do not describe their respective languages as being weakly typed although they have very similar type systems to JavaScript (and Python even says strongly typed which is just as bad). Nali4Freedom (talk) 18:37, 17 June 2013 (UTC)

I have made the edits I described above Nali4Freedom (talk) 19:17, 17 June 2013 (UTC)

"Dynamic" or "Duck" typing might be more accurate than "strongly" or "weakly" typed, but now the article says "type safe." I'm not the strongest computer science theoretician, but I'm pretty sure it's inaccurate to say that JavaScript is type-safe. At the same time I'm afraid to change it myself, due to aforementioned lack of theoretical background. Could some CS guru have a look and maybe leave some comments here about the most accurate way to describe JS type safety? GreatBigBore (talk) 19:11, 19 July 2013 (UTC)

I'm no CS guru, but describing JavaScript as type safe without further elaboration isn't really accurate. Type safety means that a language prevents type errors, that is, errors caused by treating a value of one type as if it is of a different type. JavaScript implicitly converts any type to a string, and implicitly converts from a string to other types in various cases, leading to things like '1'+1 === '11' (and also '1'+1==11). Because of this, the language doesn't raise an error when the programmer treats a value as of it were of an inappropriate type; in that sense, JavaScript is not type safe. On the other hand, these implicit conversions are all specified, so from that point of view you could argue that JavaScript is type safe. Type safety is not a particularly clear-cut idea (I don't think it's any clearer than weak vs. strong typing, TBH), and unless the article explains exactly what it means by the term, it is misleading to claim that JavaScript is type safe.VoluntarySlave (talk) 14:47, 20 July 2013 (UTC)

Javascript is truly object-oriented

From Prototype-based: Prototype-based programming is a style of object-oriented programming in which classes are not present, and behavior reuse (known as inheritance in class-based languages) is performed via a process of cloning existing objects that serve as prototypes. - I strongly disagree with the (academic) concept that only inheriteable classes are objects. Why aren' structs in C and functions in Javascript (together with the "new" operator) called what they are: Objects?! Let's face the truth: The actual use of the word "objectoriented" is wrong, because very limited. It should be called "objectoriented" (C, Javascript) and "inheriteable-objectoriented" (Java, aso.) languages. However, component-based programming works very well in Javascript, so no inheritance is needed anyway. 178.197.236.172 (talk) 15:16, 24 July 2013 (UTC)

Does regex in JavaScript come from Perl ?

Does regex in JavaScript come from Perl ? Is there a reference for this claim ?

Is there any other respect in which Self, StrongTalk and LiveScript were influenced by Perl ?

G. Robert Shiplett 00:29, 30 July 2013 (UTC)

JavaScript 1.8.6 (or even newer?)

According to: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference there is supposedly JavaScript 1.8.6 included with Spidermonkey 17 (Firefox 17). This page might be in error (someone let them know then..) since their own Spidermonkey page: https://developer.mozilla.org/en-US/docs/SpiderMonkey says 1.8.5. I say we correct the wikipedia page to match the infobox. comp.arch (talk) 14:43, 13 August 2013 (UTC)

Another relevant article about this is: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/17?redirectlocale=en-US&redirectslug=Firefox_17_for_developers

Firefox 17 for Developers does definitely not fit in the list. I suggest making an extra column to indicate when the respective version changes occurred in this developer edition of Firefox or removing the last row as a whole and setting 1.8.5 as green/lastest version. Johannes Hillert (talk) 01:33, 14 November 2013 (UTC)

Important information missing

There should be a subheading of level 2 about the action JavaScript does on certain web pages even when it's not installed on your computer. For example, in some web pages, before an image loads, it appears as a Java logo. Blackbombchu (talk) 02:12, 13 November 2013 (UTC)

There should also be a section Fake JavaScript download and under it should list the Java update virus. Blackbombchu (talk) 23:33, 13 November 2013 (UTC)

Java and JavaScript are not related, so I don't know what you're suggesting. --Golbez (talk) 20:50, 14 November 2013 (UTC)

ECMAScript standard

Concerning the following line from the article:

"A fourth edition of the ECMAScript standard was not released and does not exist. Fifth edition of the Ecmascript standard was released in December 2009."

This line, apart from its syntactic issues, needs clarification. What is meant by "does not exist"? According to this page from the official ECMAScript web site, a would-be fourth edition was under development at one time but was never completed. Vikingurinn (talk) 21:41, 8 December 2013 (UTC)

Appears fixed now. Rp (talk) 15:34, 9 December 2013 (UTC)

Claim of most used program

The second paragraph contains the claim: "It has become the most commonly used program in server-side programming, game development and the creation of desktop applications" I highly doubt this, and I am tempted to just remove it. ComaVN (talk) 09:11, 21 February 2014 (UTC)

You would be correct. Per the w3techs.com report "Usage of server-side programming languages for websites", dated 28 February 2014, the claim is at least partially false. Per that report, JavaScript accounts for less than 1% of all server-side languages. ^[8] opticsnake (talk) 21:31, 28 February 2014 (UTC)

Version History seems a little inaccurate

Generators and iterators were Mozilla-specific extensions not meant to be a part of the official standard, and were only first introduced in the ECMAScript Harmony draft as part of the core syntax. Also, the Mozilla-specific syntax is different in its entirety. I don't exactly have the time to track all the links down, but this is coming straight from the Mozilla Developer Network website. Poke around there (great search is for generators and iterators), and you will find plenty of evidence for why that table is incorrect. impinball (talk) 04:32, 9 April 2014 (UTC)

Java embedded element on the JavaScript article.

I noticed that there is a Java applet embedded on this page. Is there a reason for it to be on this page or what's going on? Does anyone else see the applet besides me? — Preceding unsigned comment added by Mnoon (talk • contribs) 00:15, 30 June 2014 (UTC)

Node.js referred in Development Tools and not Uses Outside Web Pages?

Node.js is a relatively well known application platform powered by C++ and JavaScript (preference to the latter). It uses the V8 engine, the same one that is used in Chrome. I made one edit edits to help in fixing these issues, but I don't have the time to do too many. The only common browsers that doesn't support ECMAScript 5.1 at all is IE8 (IE9 is only missing support for "use strict"). The latest version of Mozilla's JavaScript, 1.8.5 is actually based off of ECMAScript 5.1, not ECMAScript 3. impinball (talk) 01:41, 14 July 2014 (UTC)

1. ^ Crockford D (2008) JavaScript: The Good Parts. Publisher: O'Reilly Media, Inc. p.47
2. ^ Crockford D. () JavaScript: The Good Parts p. 27
3. ^ "ECMAScript Language Specification - ECMA-262 Edition 5.1". Ecma International. Retrieved 22 December 2012. 
4. ^ "Working with Objects". JavaScript Guide. Mozilla Developer Network. Retrieved 15 March 2013. 
5. ^ "Object.defineProperty". JavaScript Reference. Mozilla Developer Network. Retrieved 15 March 2013. 
6. ^ "let". JavaScript Reference. Mozilla Developer Network. Retrieved 15 March 2013. 
7. ^ "Iterators and generators". JavaScript Guide. Mozilla Developer Network. Retrieved 15 March 2013. 
8. ^ http://w3techs.com/technologies/overview/programming_language/all