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)

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)

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)

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)

<script type="text-javascript">

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)

Update the SVG

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)