Talk:JavaScript
| This is the talk page for discussing improvements to the JavaScript article. This is not a forum for general discussion of the subject of the article. |
Article policies
|
| Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
| Archives: 1, 2, 3, 4, 5, 6 |
 | Internet B‑class High‑importance | |||||||||
| ||||||||||
 | Computer science B‑class Mid‑importance | ||||||||||||||||
| |||||||||||||||||
|
|
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)
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)
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.
- 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)
- 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.
queries
what is java script and what is use ? —Preceding unsigned comment added by 203.129.201.62 (talk) 03:52, 20 November 2008 (UTC)
- Um...read the article (-_-) --Maian (talk) 19:52, 20 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.