Develop Reference

Correctly configuring Eclipse for non-web JavaScript development

Recently I've needed to write a small utility for Acrobat in its JavaScript.
Because the editor in Acrobat is pretty limited, I've installed the latest release of Eclipse IDE for JavaScript and Web Developers (Neon). It should already include the latest JSDT 2.0.
However, I've been surprised, that Eclipse's JavaScript editor does not correctly parse even simple common JavaScript patterns, like namespaces, modules, single global variable, etc. Also code folding is missing, except the very first function.
I do not expect to debug Acrobat's JavaScript code in Eclipse, but I wanted to have a smart JavaScript editor and also projects, where I could gather a few non-JavaScript resources. Some automation possibilities would be also nice, of course.
I've played with Eclipse preferences a lot and I've also searched on Internet, but I was not able to find anything really helpful.
Have I missed something in Eclipse configuration or is it really wasting of time and I should use something else?
For small projects a free IDE would be preferable, but also reasonably priced commercial products would be acceptable.
A configuration solution in Eclipse would be the most welcome, of course.
Thanks a lot for your help.

The support for newer Javascript Syntax is very bad in Eclipse (Bug).
You can use Tern.js it has a good ES5 and ES6 support.
But for Javascript development there are a lot of much better editors like Webstorm, VisualStudio, Sublime out there. You'll like more!

From my experience with Acrobat JavaScript, and the Acroforms technology (which you use when you work in PDF), there are not that many advantages you get from an IDE.
In fact, for my work (which IS extensive), a good text editor, with quote and parentheses balancing, maybe even auto-indent, and basic JavaScript code coloring is pretty much sufficient. I personally do write the scripts in BBEdit, and then copy/paste them into the Acrobat JavaScript editor window.
Keep in mind that JavaScripts in Acrobat/PDF are generally quite short, because they do not have to deal with DOM overhead, and because the field event sequence is quite structured (and it is really important to understand this sequence… more important than fancy JavaScript constructs). You also have to be aware that the JavaScript core implementation in Acrobat is relatively old (recently, they did upgrade it, but if your forms/applications are for the general public, you can't rely on them having the very newest version of Acrobat/Reader).

Javascript Engines Advantages

I am confused about JavaScript engines right now. I know that V8 was a big deal because it compiled JavaScript to native code.
Then I started reading about Mozilla SpiderMonkey, which from what I understand is written in C and can compile JavaScript. So how is this different from V8 and if this is true, why does Firefox not do this?
Finally, does Rhino literally compile the JavaScript to Java byte code so you would get all the speed advantages of Java? If not, why do people not run V8 when writing scripts on their desktops?

There are various approaches to JavaScript execution, even when doing JIT. V8 and Nitro (formerly known as SquirrelFish Extreme) choose to do a whole-method JIT, meaning that they compile all JavaScript code down to native instructions when they encounter script, and then simply execute that as if it was compiled C code. SpiderMonkey uses a "tracing" JIT instead, which first compiles the script to bytecode and interprets it, but monitors the execution, looking for "hot spots" such as loops. When it detects one, it then compiles just that hot path to machine code and executes that in the future.
Both approaches have upsides and downsides. Whole-method JIT ensures that all JavaScript that is executed will be compiled and run as machine code and not interpreted, which in general should be faster. However, depending on the implementation it may mean that the engine spends time compiling code that will never be executed, or may only be executed once, and is not performance critical. In addition, this compiled code must be stored in memory, so this can lead to higher memory usage.
The tracing JIT as implemented in SpiderMonkey can produce extremely specialized code compared to a whole-method JIT, since it has already executed the code and can speculate on the types of variables (such as treating the index variable in a for loop as a native integer), where a whole-method JIT would have to treat the variable as an object because JavaScript is untyped and the type could change (SpiderMonkey will simply "fall off" trace if the assumption fails, and return to interpreting bytecode). However, SpiderMonkey's tracing JIT currently does not work efficiently on code with many branches, as the traces are optimized for single paths of execution. In addition, there's some overhead involved in monitoring execution before deciding to compile a trace, and then switching execution to that trace. Also, if the tracer makes an assumption that is later violated (such as a variable changing type), the cost of falling off trace and switching back to interpreting is likely to be higher than with a whole-method JIT.

V8 is the fastest, because it compiles all JS to machine code.
SpiderMonkey (what FF uses) is fast too, but compiles to an intermediate byte-code, not machine code. That's the major difference with V8. EDIT- Newer Firefox releases come with a newer variant of SpideMonkey; TraceMonkey. TraceMonkey does JIT compilation of critical parts, and maybe other smart optimizations.
Rhino compiles Javascript into Java classes, thus allowing you to basically write "Java" applications in Javascript. Rhino is also used as a way to interpret JS in the backend and manipulate it, and have complete code understanding, such as reflection. This is used for example by the YUI Compressor.
The reason why Rhino is used instead of V8 all over the place is probably because V8 is relatively new, so a lot of projects have already been using Rhino/Spidermonkey as their JS engine, for example Yahoo widgets. (I assume that's what you're referring to with "scripts on their desktops")
edit-
This link might also give some insight of why SpiderMonkey is so widely adopted.
Which Javascript engine would you embed in your application?

If you want to see how the various in-browser Javascript engines stack up, install Safari 4 (yes it runs on Windows now too!), Chrome V8, Firefox 3.5, and IE 8 (if you are on windows) and run the benchmark:
http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
I believe as Pointy said above, the new Firefox 3.5 uses TraceMonkey that also compiles to intermedit code on the fly using some form of JIT. So it should compare to V8 somewhat favorably. At least it won't be 10x slower than V8 like Firefox 3 SpiderMonkey (without JIT) was.
For me... safari 4.0.3 was 2.5x faster than Tracemonky in Firefox 3.5.3 on Win XP. IE8 was much much slower. I don't have Chrome installed at the moment.
Don't know about Rhino compiling to java bytecode. If it's still interpreting the dynamic features of Javascript such as being able to add attributes to object instances at runtime (example obj.someNewAttribute="someValue" which is allowed in Javascript)... I'm not so sure that it's entirely "compiled" to bytecode, and you might not get any better performance other than you don't have to compile from Javascript source code text every time your Javascript runs. Remember that Javascript allows very dynamic syntax such as eval("x=10;y=20;z=x*y"); which means you can build up strings of code that get compiled at runtime. That's why I'd think Rhino would be mixed-mode interpreted/compiled even if you did compile to JVM bytecode.
The JVM is still an interpreter, albeit a very good one with JIT support. So I like to think of Rhino-on-JVM as 2 interpreter layers (interpreter-on-interpreter) or interpreter^2. Whereas most of your other Javascript engines are written in C, and as such should perform more like interpreter^1. Each interpreter layer can add 5-10x performance degradation as compared to C or C++ (ref Perl or Python or Ruby for example), but with JIT the performance hit can be much lower on the order of 2-4x. And the JVM has one of the most robust & mature JIT engines ever.
So your mileage will definitely vary and you probably would benefit from doing some serious benchmarks if you want a real answer for your intended application on your own hardware & OS.
Rhino can't be too awfully slow, since I know lots of folks are using it. I think it's main appeal is not its speed, but the fact that is easy-to-code/light-weight/embeddable/interpreter that has hooks into Java libraries, which makes it perfect for scripting/configuration/extensibility of your software project. Some text editors like UltraEdit are even embedding Javascript as an alternative macro scripting engine. Every programmer seems to be able to stumble through javascript pretty easily, so it's easy to pick up as well.
One advantage to Rhino is that it runs pretty much anywhere the JVM runs. In my experience, trying to get stand-alone TraceMonkey or SpiderMonkey to build & run from command line can be a bit painful on systems like Windows. And embedding in your own application can be even more time consuming. But the payback to having an embeddable language would be worth it for a big project, as compared to having to "roll your own" mini scripting solution if that's what you're looking to do.
Scripting with Rhino is really easy if you have Java and the rhino jar, you just write your javascript and run it from command line. I use it all the time for simple tasks.

To respond the question, why native code Vs Byte code...
The native code is faster and for google a strategic choice because they have plan to JS one of them at least is ChromeOS.
A good video about this question is posted on Channel9 with an interview with Lars Bak the man behind V8 can be found here

2022 Update
V8 as also SpiderMonkey do support MultiPass Compilation as also SinglePass Compilation.
Java Rhino got deprecated and replaced by a new concept called Truffle Framework it is part of the GraalVM Stack which is in fact a JVMCI added to the JVM where CI means Compiler Interface. That allows the Truffle Language Implementer Framework to Implement any Language and translate that to Java Byte Code in MultiPass and Single Pass. the ECMAScript implementation is called GraalJS and it comes in 2 Flavors
GraalJS the 1:1 Rhino Replacement including compatability mode for incremental adoption and graal-node a NodeJS Fork where v8 is replaced with the GraalJS Engine.
as sayed Truffle is a Polyglot Language Implementer Framework so that works with any GraalVM Supported Language.
hope that helps and makes some sense since the jar versions do most best work when the whole stack has aligned versions you should alaways install the complet stack:
https://github.com/graalvm/graalvm-ce-builds/releases
download and install that then use the so called gu command to add graaljs
follow the instructions here: https://github.com/oracle/graaljs
Yes GraalVM can in general Compile Single Binary Executeable Files of all Polyglot Languages this is called AOT Compilation it has faster boot times but less throughput it can also do JIT and it can do a mix of both.

Is there a good javascript plugin for visual studio?

I think that Visual Studio's biggest let down is the Javascript editor. I have been told to use Aptana as an editor for my javascript files, but I would prefer to stick with visual studio if possible.
I have read other similar plugin posts, but none focus specifically on Javascript.
VS2010 may offer some improvements, but will they be up to Apatana standards? I have briefly tested the beta, but I'm not overly impressed.
Is there anything out there that will bring Javascript closer to c# development? Considering the wide spread use of Javascript I think there must be something....... I hope! :)
Many thanks in advance... this is something that has always bugged me!

There's a couple recent plugins that may be helpful :
From Microsoft :
JScript Editor Extensions
Brace Matching
Outlining / Cold-folding
Current Word Highlighting
IntelliSense Doc-Comments Support
JSEnhancements
Outlining and matching braces highlighting
(I wouldn't think installing both of these is a good idea - and the Microsoft plugin has more features so try that one first)

VS is a pretty good IDE (especially when coupled with Resharper) but not so hot with Javascript. The debugger is good and there's the JSLint plugin but other than that I'm not sure. Aptana (based on Eclipse) is an excellent javascript IDE but it doesn't like it much when the javascript is embedded in aspx files (unless they updated the support recently). So far I'm not sure there's an ideal .net platform IDE for both client and server side stuff just yet.
Update: Resharper 6 added pretty good JavaScript support - so now I'd recommend that combination if you're doing a lot of debugging across client and server at the same time. If you're focussing on pure client code then I find WebStorm to be an excellent JavaScript/HTML IDE - even better than Aptana.

I'd really like to recommend Webstorm. It does not! treat your JS as text files.
Its a full blown JS editor and has become my favourite JS editor working in parallel with VS to handle my server side stuff.
WS has actual object intellisense across JS files. That means when I press . (dot) it shows me the functions on that objects, even if its located physically in another file.
It will recognize my objects (or their type if you will) created in other JS files referred to in the file I'm working on.
I have 'Find usages' on JS functions
I have 'find all references' on JS object / function / class / variable or whatever you want to search on. In the end its all objects but Webstorm knows this.
If I change the short/cut to F12, I can press F12 on my function call and it will jump to the implementation of that JS functon. Even if its located in another file.
Ofc. you have code folding and colouring, extract method and other neat code re factoring, overview creating tools.
Oh. And by the way.
I'd like to kill off a rumour going around in the cloud on forums I come across from time to time, looking for better ways to handle JS.
reSharper DO NOT SUPPORT JAVASCRIPT! A little piece of me dies every time I read some guy repeating what he saw on the reSharper site. It may have a some poor intellisense and some low level syntax check, but that has nothing to do with support.
Notepad++ supports JS better than VS in my opinion.
Münster

Don't forget to grab Chirpy to handle minifying your scripts in VS.

If you use Visual Studio, add the
/// <reference path="myOtherJsFile.js" />
directive at top of your js files and install Web Essentials you get pretty decent (but not perfect) intellisense, go to definition by using F12 and find all references (sort of..) by using SHIFT+F12

What would be a good browser-independent JavaScript programming environment?

My team's current project involves re-writing retrieval libraries in JavaScript. We are basically looking for a setup which enables us to apply test-driven development methods.
So far we plan to use Vim to write the code, no fancy IDE. For generating output we would use Spidermonkey's shell environment. JSLint could serve as a moderate syntax checking tool.
The essential question remains: How do you develop JavaScript (browser-independent) programs?
If we are already on the right track, then maybe you can supply us with a few tips and tricks.

You can test your code in Spidermonkey or Rhino (an older JS interpreter in Java), but you won't really know which browsers it works in until you test your scripts in them!
I agree with the earlier poster, using a browser-independent library like jQuery is probably a good idea.
I have not used Spidermonkey, but I know Rhino has a good debugging GUI, allowing the usual: setting breakpoints, watches, and stepping through code.

Only testing you'll make your JavaScript code browser-independent.

If you have the chance to rewrite it all, you might consider jQuery.
It's essentially browser agnostic. Or at least it requires much less object sniffing than plain javascript.

Yes,I'm using the same environment to develop standalone JS apps (vim + SpiderMonkey). I only would add up, that I've made small in-browser IDE for reading/writing/launching JS scripts on the server-side. Sometimes it's very helpful. Also, I'm looking for using WXJavascript project, which seems to be very promising.

Are there any JavaScript static analysis tools? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm used to having my compiler complain when I do something stupid like a typo on a variable name but JavaScript has a habit of letting this pass.
Are there any static analysis tools for JavaScript?

UPDATED ANSWER, 2017: Yes. Use ESLint. http://eslint.org
In addition to JSLint (already mentioned in Flash Sheridan's answer) and the Closure compiler (previously mentioned in awhyte's answer) I have have also gotten a lot of benefit from running JSHint and PHP CodeSniffer. As of 2012, all four tools are free open-source and have a large and active developer community behind them. They're each a bit different (and I think, complementary) in the kinds of checks they perform:
JSLint was designed to be, and still is Douglas Crockford's personal linting tool. It ships with a great default ruleset -- Crockford's own, constantly updated as he continues to learn about JavaScript and its pitfalls. JSLint is highly opinionated and this is generally seen as a good thing. Thus there's (intentionally) a limited amount you can do to configure or disable individual rules. But this can make it tough to apply JSLint to legacy code.
JSHint is very similar to JSLint (in fact it began life as JSLint fork) but it is easier/possible to configure or disable all of JSLint's checks via command line options or via a .jshintrc file.
I particularly like that I can tell JSHint to report all of the errors in a file, even if there are hundreds of errors. By contrast, although JSLint does have a maxerr configuration option, it will generally bail out relatively early when attempting to process files that contain large numbers of errors.
The Closure compiler is extremely useful in that, if code won't compile with Closure, you can feel very certain said code is deeply hosed in some fundamental way. Closure compilation is possibly the closest thing that there is in the JS world to an "interpreter" syntax check like php -l or ruby -c
Closure also warns you about potential issues such as missing parameters and undeclared or redefined variables. If you aren't seeing the warnings you expect, try increasing the warning level by invoking Closure with an option of --warning_level VERBOSE
PHP CodeSniffer can parse JavaScript as well as PHP and CSS. CodeSniffer ships with several different coding standards, (say phpcs -i to see them) which include many useful sniffs for JavaScript code including checks against inline control structures and superfluous whitespace.
Here is a list of JavaScript sniffs available in PHP CodeSniffer as of version 1.3.6 and here is a custom ruleset that would allow you to run them all at once. Using custom rulesets, it's easy to pick and choose the rules you want to apply. And you can even write your own sniffs if you want to enforce a particular "house style" that isn't supported out of the box. Afaik CodeSniffer is the only tool of the four mentioned here that supports customization and creation of new static analysis rules. One caveat though: CodeSniffer is also the slowest-running of any of the tools mentioned.

I agree that JSLint is the best place to start. Note that JavaScript Lint is distinct from JSLint. I’d also suggest checking out JSure, which in my limited testing did better than either of them, though with some rough edges in the implementation—the Intel Mac version crashed on startup for me, though the PowerPC version ran fine even on Intel, and the Linux version ran fine as well. (The developer, Berke Durak, said he'd get back to me when this was fixed, but I haven't heard from him.)
Don’t expect as much from JavaScript static analysis as you get from a good C checker. As Durak told me, “any non-trivial analysis is very difficult due to Javascript's dynamic nature.”
(Another, even more obscure Mac-only bug, this time with JSLint’s Konfabulator widget: Dragging a BBEdit document icon onto the widget moves the document to the trash. The developer, Douglas Crockford, hadn’t tried the widget on a Mac.)
10 August 2009: Today at the Static Analysis Symposium, Simon Holm Jensen presented a paper on TAJS: Type Analyzer for JavaScript, written with Anders Møller and Peter Thiemann. The paper doesn’t mention the above tools, but Jensen told me he’d looked at some of them and wasn’t impressed. The code for TAJS should be available sometime this summer.

Google's "Closure" JS compiler produces configurable warnings and errors at compile-time. It definitely finds misspelled variables and methods, plus arity mistakes. If you're willing to write JsDoc the Closure way, it can do a lot with type information, too.
The YUI "Compressor" tool can produce warnings too, but haven't tried it yet.
I haven't had much luck with the Aptana IDE, built on Eclipse, but other people like it. See Stack Overflow discussion of JS IDEs.
The IntelliJ IDE, which isn't free last I checked, has frickin' excellent JS support. It will detect and highlight misspelled vars and methods as you type, and more. It's got autocomplete, too.

In summary, JSLint, JSHint, Plato, ESLint, Google Closure-Linter are the tools available.
I faced installation issues while trying out Google Closure-Linter for Windows. But, it does mention on the web page that its support for Windows is experimental.
I found and tried another tool which works well. Here is the link for it:
http://esprima.org/
Also, this is the github link for the tool Esprima:
https://github.com/ariya/esprima

You can see some tools for JavaScript static code analysis in this Wiki.
A tool in the Wiki, but not mentioned in this post, is DeepScan.
Its focus is to find runtime errors and quality issues rather than coding conventions of linters. It covers also TypeScript, React and Vue.js.
You can try it out for your GitHub project.

I tried out ESlint and found it good..you can also add custom rules there..Here is the github repo: https://github.com/nzakas/eslint and here is the introduction to it: http://www.nczonline.net/blog/2013/07/16/introducing-eslint/

More security focused than general purpose list can be found on the Mozilla Wiki at Security/B2G/JavaScript code analysis
The purpose of this document is to collect JavaScript code analysis
tools suitable for including in coming Mozilla projects or for
internal use.
Also there is at least one commercial product that does security analysis: Burp gets new JavaScript analysis capabilities
The latest release of Burp includes a new engine for static analysis of JavaScript code. This enables Burp Scanner to report a range of new vulnerabilities, including:
DOM-based XSS
JavaScript injection
Client-side SQL injection
WebSocket hijacking
Local file path manipulation
DOM-based open redirection
Cookie manipulation
Ajax request header manipulation
DOM-based denial of service
Web message manipulation
HTML5 storage manipulation

In the commercial realm, Coverity Static Analysis supports analysis of JavaScript as of version 7.7 (mid-2015). Regarding your specific inquiry about typos, my pet project appearing in the latest release (8.0, beginning of 2016) does find typos in names of program elements.
As a key developer on the project, please accept my shameless plug: Though not yet as mature as the venerated C/C++ analysis, Coverity's JavaScript analysis shares much of the same engine, with the same focus on finding high-value defects with a low rate of false positive defect reports. We are increasing our focus on finding security defects in JavaScript (and other languages), in addition to finding general programming errors.
Now, here are some typos it finds (exact typo left as an exercise for the reader, to emphasize how easily these can be overlooked):
merge.js: (stable link) (latest revision)
commands-packages-query.js: (stable link) (latest revision)
series-pie-tests.js: (stable link) (latest revision)
outline_case.js: (stable link) (latest revision)

I like Jslint for this sort of thing...

Flow does static analysis with and without annotations.
If you need annotations, the syntax is compatible to TypeScript.
Install the package with :
npm install --global flow-bin
There's also some tooling. Have a look at gulp-flowtype and perhaps SublimeLinter-flow

JSAnalyse has just been published on codeplex.
It is a tool which analyses the dependencies between javascript files. You can even define the allowed dependencies and JSAnalysis checks whether the defined rules are fulfilled or not. That allows to keep track about the javascript dependencies even in big projects and have a clean architecture.
JSAnalyse can be executed as a command line tool or configured via the Visual Studio Layer Diagramm. It is also easy to integrate into the build. With gated check-ins you can keep the dependencies under control.
http://jsanalyse.codeplex.com/

Our SD ECMAScript CloneDR is a tool for finding exact and near-miss copies of duplicated code across large JavaScript source code bases.
It uses the language syntax to guide the detection, so it will find clones in spite of format changes, inserted/deleted comments, renamed variables and even some inserted/deleted statements.
The site has a sample CloneDR run on Google's Closure library.

Full disclosure, I'm behind this: http://www.toptensoftware.com/minime which does minification, obfuscation and a reasonable set of lint style checks.