Javascript IDE

2010-01-29

After my rip on Aptana yesterday, I figured it's only fair to try and sum up what kind of IDE would satisfy me.

Right now I'm using a text editor with simple rules for parsing. It accepts curly braces {} as scope and allows me to fold on that. It has a rudimentary syntax highlighting (a given set of keywords). It has simple and fast search and replace options. It supports macroing. It will auto complete a word that occurs anywhere above the current position in the document (so not quite auto complete :))... It also does bracket/brace matching. Yeah, I think that's about it.

Three other generic functions of the editor are key bindings. It can't fold to a function/class level (clearly, because it doesn't know about them), but the folding can at least be bound properly. Another feature that seems to be rare amongst editors is that I can press F3 and the currently selected text will be searched for in the remaining document, as if I opened the search box and entered the selection first. For some reason, none of the other editors I've seen support this, which is a real shame. Lastly, I can press a key to create a generic bookmark, more than one. Pressing another key will cycle through the bookmarks. Different IDE's handle this in different ways. PHPed will not allow generic bookmarks, only numbered. Really annoying.

The editor I use doesn't support parsing, obviously. So it won't tell me immediately when I make a syntax error. Probably the biggest pain. It doesn't support the /** doc style (expanding automatically, filling in the parameters and return value). It doesn't support auto complete, except for what I said above. No code explorer, obviously. It can fail on inline regular expressions, especially when quotes don't occur twice in them (thinking the rest is a string). And, hm, well clearly it won't support far more features, but I don't seem to be using them. And since we're talking about my ideal JS IDE here, I don't care about other feats, right now :)

There's another issue I'd like to touch, while on the subject of JS IDE's. Code exploring. This is rather difficult for dynamic typeless languages like Javascript (and PHP, Perl, etc). The IDE can only think ahead so much.

I just refactored my CDE script in an attempt to reduce its size (not yet published). I've added these two little functions:

Code: (JS)
/**
* Extend this CDE or a target object with the properties given in the first object.
* If no second object is given, obj becomes target and target becomes CDE...
* This uses a "blind" for in so do not pass on host objects...
* (eg. no testing for hasownproperty is done!)
*
* @param Object target
* @param Object obj=false If false, obj becomes target and target becomes CDE
* @return obj
*/
CDE.extend = function(target, obj){
var key;
if (!obj) {
obj = target;
target = CDE;
}
for (key in obj) target[key] = obj[key];

return obj;
};

/**
* Add all properties of the object to the prototype of the target...
* If no second object is given, obj becomes target and target becomes CDE...
* This uses a "blind" for in so do not pass on host objects...
* (eg. no testing for hasownproperty is done!)
*
* @param Object target
* @param Object obj=false If false, obj becomes target and target becomes CDE
* @return obj
*/
CDE.proto = function(target, obj){
var key;
if (!obj) {
obj = target;
target = CDE;
}
for (key in obj) target.prototype[key] = obj[key];

return obj;
};

This way I can simply do CDE.extend({hello: 'world'}); and CDE.hello will contain the string 'world'. Same goes for CDE.proto({hello: 'world'}), after that any cde object would have a property hello with the value world. It's not exactly rocket science... for us.

But that's the problem here. It will be an enormous complexity case for any parser. There are so many things that could happen in that function, as far as the computer goes, that it (most likely) can't detect the painter pattern here...

Now while there are ways around that (like detecting which methods/properties are called anywhere in the script and assuming they are also part of the object, which can be bad) I think the approach should be different. There should be a clear syntax for IDE (or any automatic parsing) hints. Something that tells the parser that some assignment or element will be a property of some class. I don't think the current "standards" can do that. PHPDoc comes short on this as well (as PHP suffers from the same problem).

I'm going to try and come up with something that tries to achieve this. Well, after I've finished my Javascript parsing project... :) I'm going to try and think of some form of documentation syntax that can give some parser some hint about what's _really_ going on in a snippet of code. More on that later.

In the meantime, if anyone knows of a Javascript IDE that might satisfy my needs, please contact me through Twitter :)