What about @param -like annotations in the top-of-the-file comment?

The devil is in the implementation. If you are thinking about implementing something like:

// #DEFINE x = "y"

then I would lobby for

// #INCLUDE x.js

where x.js has content like:

var x = "y"

Going for #INCLUDES vs #DEFINES would allow inclusion of files that are themselves self-contained libraries.
But it would also allow inclusion of emulation files – eg a file that defines either IE or Mozilla specific DOM extensions (and is probably only written so that the editor doesn't complain – never actually touches a web browser)

However, the #DEFINE approach is a start and would be useful in simpler cases.
I deal with some fairly complicated javascript library so I am looking for includes.
And if you implement the #INCLUDE feature the next thing somebody will ask for is a global #INCLUDE that doesn't need a magic comment at the top of the js files....

Anyway, if you work with big enough javascript projects you find that the browser dependencies and library dependencies keep on multiplying as things get bigger. Javascript is so loosely structured that a smart IDE can really make a difference for the poor developer.

Hello.

My company uses javascript (rhino) on the application server, so I think I can give you some input:

This javascript runs in completely different environment than the client-side javascript. There's no "document.all" or "document" as a matter of fact, but there are some other predefined classes that exist. This are all java classes and are available through the global variables.

For example:
global variable "wizard" maps to com.some.package.Wizard
global variable "log" maps to org.apache.log4j.Logger
...

So, what would be usefull is to set up an environment in the same manner as you set it now for Java files:

1. "Use these and these JARs and these directories for libraries"
2. "Declare implicit variable XXX which is of type com.some.package.XXX"
3. "Declare implicit variable YYY which is of type com.some.package.YYY"

Then, Idea could use "reflection" (in much the same way that rhino does):

class Foo {
void setBar(String s) { ... }
String getBar() { ... }

void setA(String s) { ... }
String getB() { ... }
}

From javascript:
foo.bar = 'a';
var a = foo.bar;

foo.a = 'something';
var a = foo.a; // Error - cannot read write-only property

foo.b = 'something'; // Error - cannot write read-only property
var b = foo.b;


There are plenty of HTML DOM implementations in java already outthere. This way, you would only need to say (for web-side editing):

"Declare implicit 'document' variable to be of class org.some.package.HTMLDocument" - and - voila! - it works!

(Worst case scenario: the DOM model needs to be (re)written.)

I think this could be implemented as a module-level setting. Then you could have a base "common javascript" module, and "mozilla-specific js" and "ie-specific js" modules. This is just an idea, and I think it might be overly verbose, because often you want to combine code for all browsers into one module, for convenience (or even in the same file).

Module-level setting is defenetly the way to go.

I don't see much of the GUI part yet, but first version should probably be easily implemented with just a simple table:

[Global variable name] [Class browser]

So, you would say something like:
document = org.some.package.with.html.dom.implementation.HTMLDocument
or
document = org.some.package.with.html.dom.implementation.MozillaSpecificHTMLDocument
or
document = org.some.package.with.html.dom.implementation.IESpecificHTMLDocument
or
log = org.apache.log4j.Logger

The interpreter would then work as if it had an instance of this class. How exacly is this instance created, is not important.

Later on you could probably add some "init" include functionality javascripts, that would create some javascript objects and let them be used in the code:

For example, you could have an "init.js" file that looks like this:
var SomeObject = new Object()
SomeObject.print = function() { alert("hello world"); }

After a javascript editor is invoked, this scritp would be executed, and all global objects exposed (I think that rhino at least allows you to inspect which global object exist), so that you could say in the editor something like:

SomeObject.print();


The init script could be ran once, objects inspected, their methods/properties read and cached for the next time :-)

This is possible long time ago (e.g. in Demetra), just add javascript file with definitions like
document.myproperty = 0;
and -myproperty- will be available for completion/resolve