Talk:JavaScript

Merge with Client-side Javascript

This article is mostly about Client-side JavaScript. I have proposed a merge with Client-side JavaScript. JavaScript is more abundant on the client-side so maybe Server-side JavaScript should have its own article but these should be merged or JavaScript should summarise both. What are your thought? Bamkin 19:05, 22 July 2007 (UTC)

(older 2007 comments)

I would have to disagree, They are distinctly different languages... Prophet0014 (talk) 03:10, 23 January 2008 (UTC)

Disagree with merge. While JS/ES is today most common in web browsers, there will in the future be more and more widespread alternate implementations. ActionScript, for instance, isn't the same as DOM programming. For that matter, web client programming is moving toward frameworks, a subject which clearly belongs with Client-side scripting, which doesn't seem right in a general description of the language. A big link the top saying "You might be looking for web page scripting might be appropriate instead. Shantirao (talk) 06:04, 14 February 2008 (UTC)

Disagree with merge - look at a server-side Javascript product like Jaxer from Aptana - JavaScript is not just for the browser anymore. This article deals well with Javascript as language - Client-side JavaScript deals well with an application of Javascript. Ctkeene (talk) 17:21, 9 May 2008 (UTC)

Most people care only about JS client side! So a clear difference between both is useful —Preceding unsigned comment added by 83.228.157.69 (talk) 23:43, 13 February 2008 (UTC)

I disagree. Things like aptana jaxer blur the lines between js on the client and the server, and I feel it is important to discuss both in the same article. Psychcf (talk) 12:40, 15 April 2008 (UTC)

Versions

What is "Native JSON support"? That is cited on JavaScript -> Versions but nothing was said about. The JSON was created to Javascript interpret the data directly, so that is not clear why "Native JSON support" is especial. Is it real?

Added link to JSON#Native_JSON.Jec (talk) 19:25, 28 April 2010 (UTC)

JavaScript 2?

How about something about version 2? Either in it's own section or under Language?

Yes, this is a great idea, and it warrants a new section — quite a big one; there is really quite a lot to say. Dlexc 09:58, 27 October 2007 (UTC)

See ecmascript.org. Per the versioning proposal which builds on RFC 4329, JavaScript 2 is intended to denote exactly the same language as ECMAScript Edition 4. --Brendan Eich 04:33, 23 October 2007 (UTC)

Agreed, we need to start covering the different versions of JS in this article. Psychcf (talk) 01:06, 17 April 2008 (UTC)

I was surprised to see nothing about the next version in proposal/specification/development, what Brendan Eich calls JS2. The controversy about the next generation of ECMAScript is covered in that article, but regardless it's clear there will be a JavaScript version 2 from Mozilla that will have a subset /superset of next-generation features. -- Skierpage (talk) 02:39, 2 May 2008 (UTC)

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

the debugger section is not up to date

Hello, the debugger section is not up to date anymore. Actually Opera realized its script debugger. The following sentence should be changed from

Currently, Internet Explorer, Firefox, Opera and Safari all have script debuggers available for them.

to

Currently, Internet Explorer, Firefox, and Safari all have script debuggers available for them. Opera announced a debugging developer tool in a preview released in February 2007.

Also, I would like to set an external link to the easy http request page to give some examples for http requests made by pure javascript without a huge framework behind. Also the mootools framework is very very popular and hard to find at wikipedia. On the opposite the Ajax framework page is linked everywhere. This influences a reader by suggesting the ajax framework everywhere to the believe that a framework is necessary to create a http request via javascript and leads to an improper support for the ajax framework.

However, a reader should receive a neutral overview and not be pushed to only one method.

--84.227.206.177 (talk) 03:57, 28 March 2008 (UTC)

Thanks for noting Opera Dragonfly. I updated the article. In general, make the changes you want directly rather than suggesting them here. I'm not seeing unsupportable statements in favor of frameworks in the article; edit the article or mention particulars here if you know what you want to remove. Maybe the article should mention Prototype, jQuery, Dojo, YUI, mooTools, and other popular libraries, but it should probably address them collectively rather than individually, and I strongly lean against mentioning just one. --67.119.195.0 (talk) 00:14, 19 May 2008 (UTC)

IMO, the debugger section is just too big. We shouldn't list every single debugger out there. If anything, that list should be put in its own List of JavaScript debuggers article. --Maian (talk) 15:57, 11 July 2008 (UTC)

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)

JS syntax example

The syntax example is 50 % DOM and not JavaScript. We should keep those concepts separate.--itpastorn (talk) 18:16, 6 October 2008 (UTC)

I agree. It was originally an image of JS code, but it was replaced with the text of that image. I'd like to change it, but I can't really think of a concise example that exploits all major JavaScript features with a small dose of DOM (its most common use). Of course, the DOM usage should be commented that it is not native to JS. --Maian (talk) 07:23, 7 October 2008 (UTC)

BTW, someone previously posted this image as a syntax example, but it was reverted because the image was far too large. --Maian (talk) 08:47, 19 October 2008 (UTC)

Capitalization

Shouldn't the sub headings in the features section be capitalized? I am of the opinion that it would look better that way —Preceding unsigned comment added by Higanesh2003 (talk • contribs) 11:57, 10 September 2008 (UTC)

selfref

I have moved the selfref template to the very top of this page (just below the other informational and sidebar templates) from the main article as there is really no need for the selfref to be there. Cat-five - talk 01:29, 15 September 2008 (UTC)

Function-level vs. functional programming

In the JavaScript features section, there is subsection called "functional programming". I originally wrote/revamped the JavaScript features sections (I was Special:Contributions/76.212.137.43, Special:Contributions/72.177.62.3, and Special:Contributions/72.177.62.3 when I was too lazy to log in), and I had it named "functional programming". However, User:MilesAgain changed it to "function-level programming" ([1]). Since then, it has eventually been reverted back to "functional programming". After reading that function-level programming article again, I cannot see how "function-level programming" would correctly describe that section, since conventional JS functional style definitely does not preclude the usage of variables. I just want to verify with someone knowledgeable with this subject that it really should be "functional programming". --Maian (talk) 07:52, 7 October 2008 (UTC)

I can't see JavaScript fitting in either of these categories.

[F]unctional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast with the imperative programming style that emphasizes changes in state.

JavaScript is most certainly an imperative, value-level language. First-class functions do not make it functional; they just make it extremely value-level (and I believe a functional language would also be function-level). "Imperative" is in the Paradigm section of the infobox, just below "functional," but these are exact opposites. --Jesdisciple (talk) 20:32, 17 October 2008 (UTC)

The thing with programming paradigms is that it depends on the programmer - all the language needs to do is be capable of following that paradigm. Indeed, you can program in JS in a purely functional way, avoiding state and mutable data. There's also the concept of non-pure functional languages. In fact, the posture child of functional languages, Lisp, has many non-pure functions among its various dialects. Also, here's an article expounding on the virtues of JS similarities with Lisp: http://bc.tech.coop/blog/030920.html --Maian (talk) 08:43, 19 October 2008 (UTC)

I can see a JS program successfully imitating a functional language, but I cannot see the term being part of its definition. To summarize the issue from my perspective: Should a language be classified by what a programmer can do with it or by what its features suggest? I think the former answer would drive us to flood every language with (almost) every known paradigm.

EDIT: Woops, I just remembered to check your link. That confirms my first clause above (that JS can be bent into a functional-ish shape), but, to give a practical test of the features' suggestions, I don't see any well-introduced JS newbie adopting that programming style. (This also calls its prototype-based status into question, although, I think, not as emphatically.)

EDIT2: I just had another thought. Can you actually do anything useful without having side-effects in JS? To my knowledge the DOM is the only means of output, and that entails side-effects. (I may be revealing how little I know about functional programming here, but just the same...) --Jesdisciple (talk) 01:33, 27 October 2008 (UTC)

Programming paradigms are not mutually exclusive. I think we all can accept that object-oriented programming is distinct from structural programming, yet Java encourages the usage of both paradigms. The same can be said about functional programming. Functional programming does not prohibit side effects - only "pure" functional programming does. As I mentioned before, most dialects of Lisp have several side-effecting functions, yet Lisp is considered a functional programming language.

With regards to your comment about the JS newbie, keep in mind that not everyone comes from a non-programming or a Java-ish background. Many CS students are familiar with functional programming to a certain extent and may tend to program in a functional way, and JS with its first-class functions and closures is very amenable to that (compared to say, Java). Like I said, it depends on the user. --Maian (talk) 00:51, 31 October 2008 (UTC)

I get the 'inclusivity' but still find functional JS a bit awkward. Revisiting our newbie, I would consider any considerably experienced programmer (from, Java, Lisp, PHP, or anything else) to be a biased sample. If he's already been taught to code a certain way and he knows how to do that in JS, he'll probably do it until something breaks him of it.

But I don't have any deep emotional need to win this debate; if you feel so inclined, just don't respond as I think we understand each other. --Jesdisciple (talk) 02:52, 31 October 2008 (UTC)

No notes about its lambda nature? —Preceding unsigned comment added by 65.73.82.80 (talk) 02:33, 19 November 2008 (UTC)

That's covered in the functional programming section. --Maian (talk) 07:36, 19 November 2008 (UTC)

"JavaScript is also considered a functional programming language like Scheme and OCaml because it has closures and supports higher-order functions."

This is nonsense. Why do people persist in thinking that borrowing some features from actual Functional Programming Languages makes a language Functional? Anyone who has used languages like ML or Haskell should immediately be able to see that JavaScript is a non-declarative, procedural programming language. It may allow one to adopt a programming style similar to that of FPL's, just as Monads allow an imperative style in Haskell, but that doesn't make JS an FPL any more than it makes Haskell an imperative one. I suggest this paragraph is either reworded or removed entirely. jon (talk) 16:30, 21 August 2009 (UTC)

BTW, this book [2] describes the model of execution for an FPL as thus:

• A functional program is ‘executed’ by evaluating an expression.
• The expression is represented by a graph.
• Evaluation takes place by carrying out a sequence of reductions.
• A reduction replaces (or updates) a reducible expression in the graph by its reduced form. The term ‘reducible expression’ is often abbreviated to ‘redex’.
• Evaluation is complete when there are no more redexes; we say that the expression is in normal form.

jon (talk) 16:30, 21 August 2009 (UTC)

Influenced by ScriptEase?

This edit added ScriptEase to the list of languages that influenced JavaScript. I did some research on the ScriptEase. It's original name is Cmm and was developed by a now defunct/bought company called Nombas. It was part of a larger web development framework/IDE called CEnvi. They had a page on the "history of scripting". They claim:

The advantages of client-side handling were made obvious by Nombas' "Espresso Pages", and Netscape soon began work on their own version, which they called LiveScript, and then renamed to JavaScript just before its final release.

ScriptEase eventually came to incorporate JavaScript by 2002 (may have happened earlier).

A book called "Profession JavaScript for Web Developers" by Nicholas C. Zakas, written in April 2005, also mentions ScriptEase as an influence of JavaScript.

This page also mentions Cmm:

ScriptEase (Cmm) by Nombas is being folded into the ECMA work on JavaScript.

However AFAIK, Brendan Eich has never mentioned Cmm/ScriptEase before when discussing the history of JavaScript. Cmm may have influenced Netscape to make a scripting language, and both JavaScript and Cmm share a heritage with the C language, but I'm not so sure Eich had Cmm in mind when designing the language.

--Maian (talk) 09:33, 7 November 2008 (UTC)

Just noticed that Brendan Eich already talked about this before here:

Hello. I first met Brent Noorda in late 1996, when Netscape brought JavaScript to ECMA for standardization. I had never heard of NOMBAS or its products before then. 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."

So although Cmm might have (if at all) influenced ECMAScript, it didn't influence JavaScript.

--Maian (talk) 20:19, 9 November 2008 (UTC)

Inconsistency

I just noticed that the ECMAScript says:

JavaScript was originally developed by Brendan Eich of Netscape under the name Mocha, later LiveScript, and finally renamed to JavaScript.

Wheras this page says:

The language was originally named "LiveScript" but was renamed in a co-marketing deal between Netscape and Sun,

Which is correct (i.e. was Javascript originally Mocha or LiveScript)?

Edit: Seems this article says both too.

Y Less (talk) 23:18, 29 November 2008 (UTC)

Should be Mocha (see http://weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html, http://www.infoworld.com/article/08/06/23/eich-javascript-interview_1.html) --Maian (talk) 05:36, 30 November 2008 (UTC)

Weird demographics related statements

The way this article talks about demographics" is so strange - as if use of a programming language is geography-dependent! I recommend deleting these statements.

"In regards to demographics, the language is extremely widespread in India with the United States, Russia and Ukraine also using it as a staple in their online programming. As the web continues to expand, the use of JavaScript looks like it will become more popular especially in Europe and Asia." —Preceding unsigned comment added by Mlavannis (talk • contribs) 16:17, 21 January 2009 (UTC)

Add external links to JavaScriptSource?

I'd like to propose adding an external link to JavaScriptSource.com, a site that contain a lot of JavaScript scripts, provides source code in a very readable, easy to understand manner. The site is located at http://www.javascriptsource.com/ —Preceding unsigned comment added by Sclark23 (talk • contribs) 19:12, 28 January 2009 (UTC)

First, we don't need to provide a link to a JavaScript repository site. A simple Google search suffices for that. Second, the site you're mentioning only concerns JavaScript within a browser environment. AJAX and DOM have no meaning for JavaScript outside the browser. So no. --Maian (talk) 01:58, 29 January 2009 (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)

Remove Lua Thing

Including JavaScript as being similar to Lua is pretty pointless. It's not even related and actually uses more different sytax than Java or C# do to JavaScript. Should be removed on Lua page too. Pacoup (talk) 14:41, 16 March 2009 (UTC)

From what I've heard, JavaScript and Lua have extremely similar semantics (but not syntax), and semantic similarity is just as important as syntactical similarity. But I don't really know Lua, so I can't vouch for that similarity. --Maian (talk) 13:09, 17 March 2009 (UTC)

Self-ref to Template:JavaScript bad?

This edit removed the self-ref to Wikipedia:JavaScript, but after reading Wikipedia:Avoid_self-references and Template:Selfref, this particular self-ref might be an exception. It is somewhat in context with the article. --Maian (talk) 02:04, 10 May 2009 (UTC)

JavaScript picture issues

The picture at the top shows <script type="text-javascript">, which is invalid and not accepted by IE 7 & FF 3.0.11. Also, that's a long-winded way of loading an array; a literal is nicer. Someone who knows how should update the picture. 82.163.24.100 (talk) 19:27, 19 July 2009 (UTC)

I would like to bring up that the code on the SVG at the top of the article is incorrect, outdated, and poor.

• There's an HTML tag in the code. The HTML tag must be removed; it is not JavaScript and incorrect in this context because of the .js in the corner.
• The code uses a constructor to create an array. This should be updated to literal notation as constructors aren't being used to create the strings--literal notation is.
• Some of the variables are related and would be better expressed as an object.

Using the same data, the following code would show object, array, and string notation. It is one line longer than the current text, but it appears it would still fit on the SVG.

var President = {
 fname: "William",
 lname: "Clinton"
};
var nation = "U.S.A.";
var parties = [
 "Democratic",
 "Republican"
];

Of course, the code could be rewritten all together--the text on the SVG just needs to be redone. --Quilokos (talk) 04:24, 20 July 2009 (UTC)

I have just noticed that the section above mine is on the exact same thing. Sigh. --Quilokos (talk) 04:42, 20 July 2009 (UTC)

The icon in the infobox doesn't make sense:

- It says ".js" but the text starts with an HTML script tag -- not valid content for a .js file.
- It has type="text-javascript", when it should be "text/javascript".
- The program doesn't do anything, and doesn't use array literal syntax.
- Picky, but it looks weird: the code is super-narrow, ".js" is oddly multicolored.

If you were going to redo it, I might pull the sample code from a real-world library -- jQuery, Prototype, or even the MediaWiki JavaScript (http://en.wikipedia.org/skins-1.5/common/wikibits.js). Another option is an image/screenshot from a real-world JS development scenario -- debugging JavaScript in Firebug or WebKit's Web Inspector or something. But I'd rather have no icon than this one. —Preceding unsigned comment added by 24.7.68.35 (talk) 18:04, 12 August 2009 (UTC)

I'm going to go ahead and remove the image. I can tell that it's designed to look like the images at HTML and XML but as has been pointed out, it has issues. --Maian (talk) 06:07, 14 August 2009 (UTC)

Syntax and semantics - sample code unsafe

Ignore the JavaScript structure and consider just the algorithm. That seems to be LCM(A, B) = (A*B) / GCD(A, B) which is mathematically correct.

For the case of both A and B non-negative and not greater than 2⁵³, GCD will be exact, since no value in it can then exceed 2⁵³.

However, A*B can then be as great as 2¹⁰⁶, and only rarely can numbers exceeding 2⁵³ be represented exactly as IEEE Doubles.

In particular

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

function LCM(A, B) { return (A*B)/HCF(A, B) }

LCM(111111111, 999999999)

yields 999999999.0000001 which is clearly not quite right.

It should be possible to calculate any LCM not exceeding 2⁵³ and get an exact answer, without using Math.round.

The example is unsound. It should instead, I think, be modelled on

function LCM(A, B) { return (A/HCF(A, B)) * B }

82.163.24.100 (talk) 21:01, 24 July 2009 (UTC)

Heh, I never intended the sample code to be "production quality", but I'll go ahead and make the change. --Maian (talk) 04:53, 25 July 2009 (UTC)

Update to "Uses outside web pages"

Re-Animator "is currently sleeping" (has been removed from the website, and there are no links at all for it there). I think it should be removed, or at least changed to reflect this (i.e. "allows" becomes "allowed"). —Preceding unsigned comment added by 70.119.44.175 (talk) 10:23, 21 August 2009 (UTC)

Javascript Objects and Associative Arrays

There has been discussion on using the term "associative array" in the comp.lang.javascript news group, with the concensus view that javascript objects should not be called associative arrays as associative arrays in other languages have far more features than are provided by ojbects in ECMAScript.

Objects are described in the ECMAScript specification as "An ECMAScript object is an unordered collection of properties each with zero or more attributes that determine how each property can be used." I don't see the term "associative array" there anywhere.

It also becomes confusing as Arrays are actually Objects, not the other way around.

I can understand the comment about the use of internal [[prototype]] property, but if inheritance is to be discussed, the difference between public and internal prototype properties should also be discussed.

203.8.131.32 (talk) 03:54, 8 September 2009 (UTC)

A JavaScript object has all the features of an associative array: key-value pairs with lookup via keys. I'm not sure what associative array features in other languages you're talking about. Compared to the languages that I know, there is only one restriction on JavaScript objects: the keys must be strings. Otherwise, it's basically the same thing as a Java Map, a Python dict, a Ruby Hash, or a Scheme alist (actually alist is really an array of key-value pairs, just with convenient functions to treat it as an associative array). It's called an associative array because it associates an arbitrary key with an arbitrary value (contrast with a normal array which associates a natural number with an arbitrary value). There is no intrinsic concept of ordering in an associative array. With that said, JavaScript objects aren't exactly associative arrays, because they're augmented with prototypes.

A JavaScript Array can be explained like this: it's a JavaScript object (associative array augmented with prototype) with a magical "length" property whose value is the highest integer property (represented as a string, of course) in the object, plus one. Compared to other languages, it's a very augmented Array data type.

I'd rather not have to discuss how exactly inheritance works in JavaScript, because it would basically be repeating what's in Prototype-based programming, which is already linked from the features section. In any case, the notion of "private properties" is merely a specification detail. It's only relevant to the JavaScript engine; the user only needs to know that an object has a prototype, which is not a "property" in the JavaScript sense (e.g. not a key), and that Function objects have a property named "prototype" whose value is the prototype of objects created via that function.

--Maian (talk) 07:43, 8 September 2009 (UTC)

Boolean data type

The following section was removed from the article Boolean data type:

begin removed text

JavaScript has two keywords true and false, both of which are written in lowercase. It is a weakly typed language and does not have an explicit Boolean data type for its variables. However many values will evaluate to false when used in a logical context, including zero, null, zero length strings, and unknown properties of objects. All other variable values, including empty arrays and empty objects, will evaluate to true. The language does offer a Boolean object which can be used as a wrapper for handling Boolean values. The Boolean object will always evaluate to true even if it has a value of false.

var objBool = new Boolean(false);

if ( false || 0 || "" || null || window.not_a_property ) {
    alert("never this");    
} else if ( true && [] && {} && objBool ) {
    alert("Hello Wikipedia");             // will bring up this message 
}

end removed text

Is there a place for this text in the Javascript-related articles? Perhaps in the Wikibook? Thanks, and all the best, --Jorge Stolfi (talk) 23:46, 30 December 2009 (UTC)

You can put that here: JavaScript syntax#Boolean. --Maian (talk) 08:06, 31 December 2009 (UTC)

History section - JavaScript and JScript

In the history section the following sentences appear - The dialects are perceived to be so similar that the terms "JavaScript" and "JScript" are often used interchangeably. Microsoft, however, notes dozens of ways in which JScript is not ECMA-compliant.

I haven't found any evidence for the first sentence, and it seems to cause more confusion than it removes. I think the second sentence belongs in the article on JScript.

Any comments or insight into this before I do something with these two sentences?

DonToto (talk) 05:41, 2 June 2010 (UTC)

Agreed. We must stick to referenceable facts, not things that someone wished were true. --Nigelj (talk) 08:38, 2 June 2010 (UTC)

Another note - I think that in the table of Versions, the line(s) relating to JScript would be more appropriately placed somewhere else (even as far away as the JScript article), since JScript is not JavaScript. Perhaps what is needed is a clear statement of the nature of the relation between JavaScript and JScript, and why we should be interested in JScript if we are interested in JavaScript. This is already addressed, at least partially if not completely, in other places in the article. DonToto (talk) 05:58, 3 June 2010 (UTC)

JavaScript and Java

I am putting these thoughts here for discussion before attempting any further changes based on them. I think the relation between JavaScript and Java could be a little more carefully explained. First, the section titled "JavaScript and Java" should be placed outside the current section ("Related languages" seems to be a section devoted to languages using JavaScript as a starting-point.) Second, the statement "A common misconception is that JavaScript is similar or closely related to Java; this is not so." is not really so; if you think about it, the opposite is true! Possibly the problem is that vague words are used - there is something trying to be said, but it's not coming out clearly. As an analogy, Visual Basic and VBScript (Visual Basic Scripting Edition) have a similar relation to each other as do Java and JavaScript, but there does not seem to be the same amount of space devoted to how they are different, or why (This may not be an analogy that I can put in Wikipedia - not sure about this, as I am new to Wikipedia writing.) DonToto (talk) 06:13, 3 June 2010 (UTC)

Good points. I changed the intro text to be less ambiguous and more encyclopedic. Let me know what you think. If you agree then other text should be changed also.   Thx, Daniel.Cardenas (talk) 00:23, 12 June 2010 (UTC)

Yes, I agree, much better. By removing the words "Despite the ..." and "however" the style is more neutral. I would just suggest to follow the content of the attributable reference (Language overview) a little more closely. First I'll put the suggestion, then I'll put the quotation from the reference.

The key design principles within JavaScript are taken from the Self and Scheme programming languages. The syntax of JavaScript is similar to that of C++ and Java, and JavaScript copies many Java names and naming conventions.

The ECMAScript Language Reference referenced in the article has the following on page 4, from which I quote directly, and I think we can deviate from the content of this reference only at our peril (:>).

ES3 is a simple, highly dynamic, object-based language that takes its major ideas from the languages Self and Scheme. The programming style is a mixture of object-based and functional programming: ... ES3 has syntax reminiscent of C++ and Java™ and provides control structures like loops and exceptions; it also has a rich library of predefined data types—arrays, strings, numbers, dates, regular expressions, and more.

Other attributable sources (e.g. interviews with Brendan Eich) state that he copied Java syntax, that is, he had Java as his model when he designed the syntax. DonToto (talk) 03:19, 12 June 2010 (UTC)

Suggestions (about Examples and other content)

First, I am thinking it might add clarity and be helpful if like in some other programming language articles the examples were moved from their existing locations and put into a section called "Examples". Comments?

Also it would probably be helpful to add some comments along with putting in an Examples section. DonToto (talk) 04:34, 15 June 2010 (UTC)

Second, I am wondering if most of the content in the section "Use in web pages" belongs better in another existing article such as "client-side JavaScript" or "client side scripting". Most of this content is not about the JavaScript language per se but about these application development issues. It's all great content and I'm suggesting only that it be moved. By being in the article, it suggests that people using JavaScript need to be aware of it, but it's only developers / users who are doing client-side scripting, and even then not necessary with JavaScript. —Preceding unsigned comment added by DonToto (talk • contribs) 03:31, 11 June 2010 (UTC)

JavaScript and Scheme?

The syntaxes differ but the little I understand, JavaScript is a Scheme interpreter, i.e. a list processor (LISP) with lexical variables. Rursus dixit. Also: being a Scheme, the horrible garbs are unavoidable. Rursus dixit. (^mbork³!) 10:40, 23 June 2010 (UTC)

Already there! Pardon for repeating the obvious! Rursus dixit. (^mbork³!) 14:57, 28 July 2010 (UTC)

Next Version Number

The preview release of Firefox has been renumbered from 3.7 to 4.0, and Gecko 1.9.3 is being renumbered to Gecko 2. [3]

So what is the version number for JavaScript in the preview release?

possibly date info

The article say (in the large chuck of code section):

// Note: Array's map() and forEach() are predefined in JavaScript 1.6.

// They are currently not available in the JScript engine built into

// Microsoft Internet Explorer, but are implemented in Firefox, Chrome, etc.

It is not clear what version of Interent Explorer it is talking about - I don't think this is true in IE8. Also, even if it is true now it should be phrased in an "As of" style (http://en.wikipedia.org/wiki/Template:As_of%3F). Or refer explicitly to versions. J. in Jerusalem (talk) 13:15, 16 August 2010 (UTC)

version 5

It should be mentioned that browsers are starting to implement ECMAscript 5 features. Will the next major version of Javascript also be 5?--81.182.55.167 (talk) 15:57, 28 August 2010 (UTC)

Browsers javascript support

The article states that Google Chrome 6+ supports js1.7 - iterators, generators etc. I tried to run js1.7 code on latest Chromium build (7.0.549.0), but application throwed SyntaxError. Also I couldn't find any information regarding current V8' js support. I think, we need to remove uncorrect information Prowdtobegeek (talk) 16:49, 7 October 2010 (UTC)

"Now we display..."

I'm not happy with the terminology, "Now we display..." and "Now we show..." in the examples. Could somebody come up with a more encyclopedic formulation? --Nigelj (talk) 10:52, 14 October 2010 (UTC)

Much-needed cleanup done. --Cybercobra (talk) 11:19, 14 October 2010 (UTC)

Thanks. Much better. --Nigelj (talk) 12:31, 14 October 2010 (UTC)

Less code and maybe a section about implementations?

The amount of sample code seems excessive -- it should exist on the Internet but not in a Wikipedia article.

Also, I see there are great links about implementations in the ECMAScript infobox, but maybe there could be a summary of the history/current situation in a (sub)section. At least noteworthy that there are two classes of JS implementation: the older engines (like you'd find in IE8/FF3.0/Safari 3.0) and then the generation in all modern browsers (counting IE9) that can handle entirely new classes of apps (graphics, parsing, etc.). —Preceding unsigned comment added by 67.121.114.161 (talk) 04:51, 21 November 2010 (UTC)

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)

Spoken Wikipedia Audio Recording

I've uploaded an audio recording of this article for the Spoken Wikipedia project. Please let me know if I've made any mistakes. Thanks. --Mangst (talk) 20:43, 13 December 2010 (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)