Talk:JavaScript/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

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)

This is tricky. I think JavaScript should include the content from Client-side JavaScript. For a strong majority of JavaScript programmers, JS is a language for scripts in Web pages; that's also its origin. The article should still note as it does now that JavaScript has been picked up in other environments, but it should have the content that readers were (probably) looking for. (Perhaps "Uses outside Web pages" could be a shorter section with a link to an external article.)

Separately, I hadn't looked at Client-side JavaScript until now, and I'm a little wary about how much of it is sample code and detailed mechanics---it reads a little like a textbook, which Wikipedia is not. (See also this style guide entry on code samples.) In other words, we may want to cut out some those code samples before, during, or after any merge, and link to a tutorial or LiteratePrograms instead. On the other hand, all of the links in Client-side JavaScript and many of the additional facts (e.g., about why browser detection is pervasive but bad) are just divine.

Finally, most of the content from both articles about compatibility may belong in Web Interoperability, but that's another matter entirely.

Most of what I just said was offtopic. The point is: I favor merging Client-side JavaScript into JavaScript because it will more quickly get readers to the information they want. Conflict of interest notice: I just edited JavaScript heavily, especially the "Security" and "Compatibility considerations" sections, and obviously I have a little bias in favor of my prose. 75.24.110.218 00:30, 23 July 2007 (UTC)

(This is the same person as 75.24.110.218, at a different IP.) I'm willing to start merging Client-side JavaScript into JavaScript. I won't touch Server-side JavaScript and will put code samples somewhere outside JavaScript (not sure where yet).75.23.153.79 19:49, 25 July 2007 (UTC)

The problem is not in the existence of the client-side JavaScript article, but in the fact that most of its content should be part of this article. It should be shortened, I believe... Booles 18:53, 23 August 2007 (UTC)

I disagree, as Javascript is it's own distinct entity: simply a scripting language. Various implementations and uses for Javascript, such as client-side scripting for which it was originally deployed, are also distinct entities. —Preceding unsigned comment added by 204.248.57.243 (talk) 21:40, 3 October 2007 (UTC)

I agree, but it may make the article very long. Tonyf12 15:50, 21 October 2007 (UTC)

I agree that there is a problem, but I disagree that a merge is the answer. Apart from the Use in web pages section, the Javascript article is very well weighted (about the same size for each section) and reads well. The problem as I see it is that the CSJS article is not properly linked from Javascript so people aren't finding it, and does not contain all the information it should — the subsections within Use in web pages should be major sections within CSJS. The linking can be improved by making the CSJS a Main Article link from the Use in web pages section, and also making it the first link within the See Also section at the bottom of the page. Dlexc 10:41, 27 October 2007 (UTC).

Disagree with merge. Javascript / ECMAscript is a language, and like many languages (e.g. C++, Java) can be implemented in many environments, and its possible uses depend on the facilities (object model / API) provided by each environment - and other languages can be used for similar functions, e.g. VBscript client-side and server-side. There's enough to say about Javascript (per se), Client-side JS and Server-side JS to justify 3 articles.

After looking at Client-side JavaScript I'd be more inclined to merge Client-side JavaScript into Client-side and retitle the latter to "Client-side scripting", since most of the info that needs to be provided about client-side scripting applies equally to JS and VBS.

At present I'd be inclined to keep Server-side JavaScript as an article in its own right, because it's quite possible that the way JS is used in the various server environments varies a lot (MS's ASP is the only one I know even slightly of those that support JS).

Otherwise I agree with Dlexc that re-factoring and cross-linking should be improved. Philcha (talk) 01:37, 16 December 2007 (UTC)

Security risks

The following attack does not use any error, exploit or backdoor. Should wikipedia include this kind of information? What about this specific case where it is not a flaw but something inherent to the way javascript works?

From: http://www.spidynamics.com/spilabs/education/articles/JS-portscan.html

Imagine visiting a blog on a social site or checking your email on a portal like Yahoo’s Webmail. While you are reading the Web page JavaScript code is downloaded and executed by your Web browser. It scans your entire home network, detects and determines your Linksys router model number, and then sends commands to the router to turn on wireless networking and turn off all encryption. Now imagine that this happens to 1 million people across the United States in less than 24 hours. This scenario is no longer one of fiction.

The fact that JavaScript is involved in much security-related discussion seems worth mentioning in wikipedia. The particular example is only one of many. Wikipedia, and this article, do not seem to me the right place to hold a detailed discussion of such risks, and I'm not sure it can be properly understood without that. Likewise, public discussion of vulnerabilities is most clearly appropriate when it's done in a way that encourages and facilitates their repair; in this case, given the unreasonability of expecting general users to follow the discussion, a browser-vendor security forum seems more appropriate. Jackrepenning 23:01, 20 November 2006 (UTC)

I've already mentioned the possibility of JavaScript trojans, which simply rely on the by-design behavior of Windows Script Host and are very rare "in the wild." If we split off a "JavaScript security" article, we could mention port-scanning there without it feeling excessive or out of place. My gut feeling aside, I haven't dug deeply into the Wikipedia criteria for what's worthy of mention in an article. 75.24.110.218 04:15, 23 July 2007 (UTC)

I agree that the URL from spidynamics.com may not belong in this article. That's because we don't have a third-party assessment of how important that vulnerability is. The amount of security coverage in the present article seems about right to me, though it could be written in a more unified manner. It talks about modes of attack rather than how to defend yourself which is more significant to average users. There's no reason why we couldn't have a separate article called Javascript security if were neutral, well-referenced and balanced. It could be somewhat more technical than this one. However, someone would have to sit down and write it. EdJohnston 05:26, 23 July 2007 (UTC)

The security problems are not caused by JavaScript itself but by the environment in which it's implemented. For example 75.24.110.218 (04:15, 23 July 2007) rightly mentioned "JavaScript trojans, which simply rely on the by-design behavior of Windows Script Host", which is used in HTML Applications, which can install malware becuase they can write files and registry entries. HTAs can be written in either JavaScript or VBScript. I think that HTAs are dangerous mainly because Internet Explorer fails to: (a) distinguish between use of scripting for DHTML (should be safe) and for HTAs (potentially dangerous); (b) treat attempts to intall HTAs as a potential security hazard (users get no warning they way they do with .exe files). Philcha (talk) 11:36, 23 January 2008 (UTC)

JScript in WSH

I think some mention of the use of JScript in Windows Scripting Host should be made. One can effectively write full-blown application using JScript. -SharkD 13:49, 24 October 2006 (UTC)

Actionscript

Along with some copy editing, I changed the reference to ActionScript. It obviously does conform to the ECMAscript standard, otherwise Mozilla wouldn't have adopted the ActionScript VM code the other day. Chris Cunningham 01:12, 11 November 2006 (UTC)

I don't know the actual status of ActionScript (so I'll not touch that), but conforming to the standard has very little to do with whether they adopted the VM. Considering they didn't take the actual language parsing part it seems unlikely it'd have to conform. 77.99.113.146 (talk) 10:38, 15 December 2007 (UTC)

Refs section

This seems indiscriminate. These should be moved into ref tags if directly relevant to the article. Chris Cunningham 14:58, 24 November 2006 (UTC)

History and overly fast archiving

Looking back at the history section of the Archive1 one sees that the issues brought up there are still not taken care of.

To expand on this, the sentence As of 2006, the latest version of the language is JavaScript 1.7 makes for even more confusion whre there is a web page dedicated to Javascript 2.0. Something to clarify versions, relations to Ecmascript versions and dates would be helpful. I have looked but am sufficiently confused by what is claimed that I am not in a position to contrubute.

Just please don't archive this before it is solved. --17:37, 30 December 2006 (UTC)

That link is an old Netscape proposal that hasn't been updated in years. The latest available version of JS is 1.7. The correspondence between JS and ECMAScript versions is described at the ECMAScript page. --asqueella 16:25, 2 January 2007 (UTC)

Unclear sentence about "PnP JavaScript design pattern"

I removed the following sentence from the article because it seemed to lack sufficient context to make clear what was meant.

PnP JavaScript design pattern was adopted gradually after commonly use of Ajax to reduce JavaScript maintenance cost.

What is a "PnP JavaScript design pattern"? And, if we are going to say it was adopted, we need a source. 75.214.198.187 (really User:JesseW/not logged in) 04:34, 10 February 2007 (UTC)

Run-on sentence

The sentence:

Since JavaScript is interpreted, loosely-typed, and, when run at the client-side, may be hosted in varying environments, applications, implementations and versions, the programmer has to take extra care to make sure the code executes as expected in as wide a range of circumstances as possible, and that functionality degrades nicely when it does not.

Is way too long and unclear. It needs to be broken up into pieces, and simplified. I attempted to do so, but couldn't get it to work. I came up with: "JavaScript has a number of features that make it Because the same JavaScript code may be run in a large variety of circumstances, extra care must be taken in testing it.", but that leaves out too much of what's in the original. Suggestions are greatly appreciated. 75.214.198.187 (really User:JesseW/not logged in) 04:53, 10 February 2007 (UTC)

How about:

JavaScript is an interpreted and loosely-typed programming language. JavaScript code is also often passed to web browsers and other web 'user agents' to be run at the client-side, and so will be interpreted in varying environments, applications, implementations and versions on various end users' machines. This means that the programmer has to take extra care to ensure that the code executes as expected in as wide a range of circumstances as possible. There will always be the possibility of total failure in the final execution environment, so it falls to the software designer to ensure that the end user's perceived functionality degrades nicely in those cases too.

I'm afraid the reason it wasn't clear was because it was rather terse, probably to try to make it all work as one massive sentence. When clarified, it gets longer, not shorter: but if that makes it more helpful to the reader, then it is not a problem. What do people think? --Nigelj 23:58, 10 February 2007 (UTC)

That's certainly an improvement, and I suggest you replace the existing sentence with that. Nevertheless, it's not optimal... It'd be better if there was a clear topic sentence; maybe "The same JavaScript code is often run in a wide range of circumstances, due to the language's dynamic features and it's typical client-side execution." followed by what you wrote. Thanks for your suggestion! 75.214.202.6 (really User:JesseW/not logged in) 06:51, 11 February 2007 (UTC)

Programming

Why isn't this javascript entry marked as a programming language?

External links

The external link added earlier today seems to be commercial and non-notable; also, its grammatic errors resemble the grammar used on the linked website, suggesting the possibility that the link was added by someone from that site, promoting it. Its non-notability seemed reason enough to remove it, which I've done. Another link that seems a candidate for removal is the one listed as "Installing & Configuring JSDoc On Windows...." I'd appreciate someone else's opinion of that one. Thanks, --rich<Rich Janis 08:42, 2 July 2007 (UTC)>

Mobile

So how is JavaScript implemented on the popular Microbrowsers? Openwave, Opera Mini or the Nokia or Motorola browsers? Mathiastck 12:16, 19 July 2007 (UTC)

external link

It could be interesting to add this external link to show how advanced is the JavaScript language. Unfortunately it is so usual to see only examples related to browers DOM.

• JavascriptTips Advanced examples of JavaScript code.
  • nobody seems to be against, so I'll put on the page in the link section —Preceding unsigned comment added by 193.253.60.213 (talk • contribs) 10 August 2007

I don't see why this link is justified under WP:EL. The text of WP:NOT asserts that Wikipedia is not a directory or a how-to manual. It is not our job to provide a directory of useful links. Especially something like JavaScript is very easy to document with a Google search. Nothing in the present text of the article cites code.google.com or uses it as a reference. I will wait to see if anyone else chimes in here to support inclusion of your link, before removing it. EdJohnston 01:01, 11 August 2007 (UTC)

• • • I am a wikipedia user and I am ALWAYS happy to have further information about a topic. EdJohnston, have you already tried to to search "javascript" with google ?... ( and BTW, code.google.com is a hosting site, like Sourceforge and many other ) WP:EL said: Such pages could contain further research that is accurate and on-topic; information that could not be added to the article for reasons such as copyright or amount of detail —Preceding unsigned comment added by 82.231.70.117 (talk • contribs) 12 August 2007

External Links section is now appropriate

The JavaScript article isn't watched as closely as articles like List of search engines for newly-arriving spam. Just want to put in my two cents that, as of this exact moment, everything in the section is now (IMHO) appropriate, and fully complies with WP:EL. Each link is tied either to a standards body, a major group like Mozilla, or somebody who is famous in the JavaScript world, like Brendan Eich or Douglas Crockford. Unfortunately, the article needs almost daily attention to keep new promotional items from being added. You can help! EdJohnston 03:23, 17 August 2007 (UTC)

• Since discuting about this article seems unfortunately useless ( cf. previous topic ) and a waste of time, I took the initiative to remove useless/duplicate links myself. —Preceding unsigned comment added by Soubok (talk • contribs) 17 August 2007

Cross-site vulnerabilities

"XSS vulnerabilities can also occur because of implementation mistakes by browser authors."

should be changed to something like:

"XSS vulnerabilities can be the result of website's programming, which includes lack of, or incomplete, user inputted data validation and unperfect defense against attacks based on "character encoding" issues ,and implementation's mistakes made by browser authors. Javascript, and its use by the attacker, is not the cause of XSS vulnerabilities, but one of the possible uses when taking advantage from them."

In the end of the section you can add:

"Both XSS and XSRF vulnerabilities use, can produce damaging results even not using Javascript." —Preceding unsigned comment added by 213.13.230.160 (talk) 02:32, 3 September 2007 (UTC)

I wouldn't recommend the above change because it is too confusing. For example: Javascript, and its use by the attacker, is not the cause of XSS vulnerabilities, but one of the possible uses when taking advantage from them. You argue that JavaScript is innocent of the problems caused by cross-site scripting, but I can't follow your reasoning. EdJohnston 17:42, 20 September 2007 (UTC)

I think what 213.13.230.160 is trying to say is that Cross-side scripting isn't limited to JavaScript. XSS happens when data isn't sufficiently escaped to prevent script code from being displayed on the site - so the site ends up sending script (in this case, JavaScript) to the client, despite not wanting to. The harmful JavaScript code isn't any more or less harmful because of the XSS. So, indeed, JavaScript is "innocent" in regards to XSS - but not in regards to the problems caused by the code.

In other words, a lot of XSS takes advantage of problems with JavaScript by injecting bad JavaScript code - but XSS itself has nothing to do with JavaScript. If JavaScript fixed it's vulnerabilities to certain code, then it might not be used for XSS attacks anymore; but XSS would prevail.

Does that help clarify? (I bet I just complicated everything...) -pinkgothic 11:33, 15 October 2007 (UTC)

Curses. Pardon the P.S., but I just want to say that was rather sloppy of me - I forgot to address the "and implementation's mistakes made by browser authors" part, which is particularly icky since it leaves things I've said look stupid without elaboration. As I see it, JavaScript already is an implementation of ECMAScript, unless I'm mistaken (and I might well be, since I'm not too sure it meets the definition of "implementation"). Anyway, case in point, IE uses JScript (which obviously has its issues, too). Hence my referring to JavaScript and fixing-its-issues in the previous section.

If it bothers someone, just replace "JavaScript" with "the browsers' implementation of JavaScript" in the respective lines. Sorry about that. -pinkgothic 11:48, 15 October 2007 (UTC)

This is still not clear to me, though your point may be valid. Could you possibly find a reference that has commented on this issue, even a blog posting somewhere? EdJohnston 17:08, 21 October 2007 (UTC)

A quick search on Y! came up with this. Quick quote:

"What are the threats of Cross Site Scripting?"

Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application [...]

In consequence, JavaScript(/JScript) is often used for XSS, but XSS itself is a separate issue from any JavaScript vulnerabilities. I hope that helps clarify. :) -pinkgothic 13:45, 5 November 2007 (UTC)

history of criticism

I was thinking it might be helpful to have at least a brief mention of JavaScript's arguably controversial history. In my experience as someone who's been on the 'net for the better part of the last 20 years, initially JavaScript was met with derision or outright hostility, not necessarily because of the language itself but because the implementations in browsers -- or the code written by users -- had lots of flaws that degraded the Web experiences for many users. However, in recent years this reputation is being rehabilitated by the usefulness of JavaScript in "AJAX" applications and by better client support. I thought a sentence or two might be warranted along the lines of "In its early years, JavaScript met with criticism both from the quality of its implementation in browsers and from the quality of code written by Web site authors. However, since the W3C Dom and AJAX started to become an increasing part of the Web experience, JavaScript has become a much better regarded and much more appreciated part of the modern World Wide Web." ----anyone have thoughts or ideas on where to get cites for this? I'm sure there are other people out there who will agree with my experience of JavaScript's history. 68.55.1.33 23:09, 22 September 2007 (UTC)

It's worth looking for cites. However the RSS article experiences a similar problem with its history in that it may be getting too large. (There is now a separate article called History of web syndication technology). In an article like JavaScript it is probably more important to look for live issues or unresolved problems, where progress may still be expected to occur. For example, security is still a live issue. Old issues that are fully solved may be of less interest, unless they help to illustrate the concepts. EdJohnston 17:01, 21 October 2007 (UTC)

This is a very good idea; what you describe is definitely what has happened, but it will need lots of citations to make it work. I think a single sentence within the introduction would be a good place for this. Something like "Javascript was originally seen as a toy language by many in the industry [quote] and was also avoided because of compatibility frustrations within early browsers [quote], but is now more widely seen as a strong language that was just initially misunderstood by many [quote]. Dlexc 09:55, 27 October 2007 (UTC)

Didn't Netscape submit JavaScript to the ECMA ?

The sentence "Microsoft submitted JScript to ECMA for standardization resulting in the standardized version named ECMAScript." makes me believe that Microsoft induced the development of the ECMAScript standard. In a book about JavaScript and at http://developer.mozilla.org/en/docs/A_re-introduction_to_JavaScript Netscape claims to have submitted JavaScript to be standardized by the ECMA. Lukenet 07:51, 7 June 2007 (UTC)

Netscape submitted JavaScript to ECMA in November, 1996. See the Netscape press release. --Brendan Eich 04:24, 23 October 2007 (UTC)

Javascript a JVM language?

Javascript is categorized as a JVM programming language, but i don't see any reference to it. Either this is a mistake and should be corrected or a reference should be made somewhere. Who can help? Bouke 15:37, 14 March 2007 (UTC)

See Rhino documentation. Rhino is bundled in Java SE6 behind the JSR 223 interface. --Brendan Eich 04:29, 23 October 2007 (UTC)

History

I think the History section is a bit thin. Some examples of enhancements at each stage would be useful. Martin Packer (talk) 10:12, 21 November 2007 (UTC)

Distinguishing Characteristics - restructure

I've restructured "Distinguishing Characteristics"in order to:

• Make the flow IMO easier to follow - first dynamic typing (applies to everything); then characteristics of objects in JS (assoc arrays; prototype chain; dynamic properties and methods); then functions (constructors; custom properties; closure); then dependence on an object model provided by the runtime environment, finally built-in functions and regular expressions.
• Provide more explanation and examples. IMO the previous version assumed too much familiarity with JS, scripting languages and other (non-scripting) languages. I suggest an article for the general reader should assume at the very most a casual acquaintance with BASIC.
• Explain important features which are probably not stated in so many words in the ECMAscript spec but are important logical consequences of the spec, and are not obvious to beginner JS programmers and therefore even less obvious to the general reader.

I'm sure others will have their own ideas, but I hope they will follow the principles of grouping relating topics together and make it easy for the general reader.

I'm not sure "Distinguishing Characteristics" is the best title, since other languages have similar features (notably VBscript). What about "Major features"? Philcha (talk) 12:57, 16 December 2007 (UTC)

Actually, I'd like to compress this section as much as possible. It currently has 12 entries - enough to bore the casual reader. Admittedly, I added plenty of prose to the section as well, but now that I look at it, it just looks bloated. This should be a "JavaScript at 1000ft view" type section.

With that said, I propose moving some of the prose for certain hard-to-understand features to another section that would explain them more thoroughly and holistically, e.g. prototypes, constructor vs. class, this object, closures.

Entries I think are unnecessary: "facilities determined by the run-time environment" (applies to any scripting language), "large collection of built-in functions" (plenty of languages have builtin functions too, and JS actually doesn't have that many).

I find the "dynamic addition / deletion of object properties" as a separate entry redundant too, since that's implied under the "object = associative list" entry.

--70.132.207.182 (talk) 02:25, 17 December 2007 (UTC)

I understand what you're saying, but I think we need to cater for general readers who are not already familiar with Javascript or other programming / scripting languages. The item I'd most willingly forgo is closure - I'm not sure I fully understand its significance even now, and I've written JS that exploits all the other features (closure reminds me of the man who discovered he'd been talking prose all his life). An alternative approach might be to focus on ways in which one can use JS more flexibly than most other languages, but then one needs dynamic typing, prototyping, dynamic custom properties, etc. in order to explain why. Philcha (talk) 04:51, 17 December 2007 (UTC)

Here's a rough roundabout way to describe closures: Suppose you have function foo that contains var x and function bar, and bar uses x somehow, and foo returns the function bar. Once foo finishes executing, one would think that x would be deallocated, but if that were done, the returned function bar would no longer work. JavaScript makes sure bar has a reference to x (actually, a reference to the scope/local/activation object of foo), so that x won't be deleted until bar itself is no longer accessible. x is said to be closed here, hence the term closure. Just look at the closure (computer science) article for elaboration (see the example code).

How about this: categorize each feature. The intro already states that JavaScript is a: scripting language (incl. environment), dynamic (incl. dynamic object, dynamic typing), functional (incl. closures, first-class functions, variadic arguments), and prototypical (constructors, prototypes). That's 3 categories. Then there would be a final category for all the other features: regexes, weird this object.

I still think "large collection of built-in functions" should be removed, since not only do most other languages (whether scripting or not) have a library (incl. functions and classes), JS's library is actually relatively small, so "large" is incorrect.

BTW, I like "Major features" as a title better than "Distinguishing characteristics".

--70.132.207.182 (talk) 07:58, 17 December 2007 (UTC)

Also, keep in mind, we're not teaching JavaScript nor are we supposed to be detailed about it in the section. We teach it at wikibooks:Programming:JavaScript and we detail it at JavaScript syntax. So this section needs to be a broad overview with little detail. (BTW, this is the same user as 70.132.207.182 above - I just happen to be mobile and I'm too lazy to login.) --76.201.21.139 (talk) 17:23, 19 December 2007 (UTC)

Do we really need an external link to http://www.fortifysoftware.com?

Per this edit, an editor has added an external link from this article to www.fortifysoftware.com. I question the need for introducing an external link here, since we already have a Wikipedia article which is linked to, Cross-site request forgery. Also, fortifysoftware.com does not appear to be a reliable source, so it shouldn't be a reference for matters of fact. (Though it's not really being used as a reference, since no factual claims are attributed to it). EdJohnston (talk) 22:08, 28 January 2008 (UTC)

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6