Talk:JavaScript

"Javascript hijacking"

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

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

- tychay (tchay@wikimedia) (talk)

Lede too jargony

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

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

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

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

IO functions

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

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

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

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

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

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

Added an example

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

No longer a 'client-side' language

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

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

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

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

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

"Vendor-specific extensions"

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

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

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

• property getter and setter functions
• proper block scope via the let keyword
• generators and iterators