So, I’ve spent an interesting couple of days learning Objective-C, Cocoa and nosing around the Apple developer documentation in order to see how to get at the JavaScriptCore. And, as far as I can see, you can’t.

The best I came up with is Using JavaScript From Objective-C. Which sounds nice and well, but from what I can make out, it’s predicated on having a window hanging around, which I want to avoid (I want a command line tool). It also doesn’t provide any interfaces to bind your own functions into the JavaScript interpreter.

Now, JavaScriptCore happens to be one of the Open Source parts of OSX. So, I can just download it, build my own wrapper, and so on. But it is annoying that I have to do so when the system comes with a perfectly good JavaScript interpreter of its own. Not only that, but it’s an alternative implementation to spidermonkey (based on KJS from KDE). And more implementations usually leads to a healthier ecosystem for a programming language.

In the meantime, anybody wanting (relatively) quick access to a lint for JavaScript on osx should probably look at javascriptlint instead. It still needs compiling, but it produces a single file which has no dependencies.

Mind you, I’m still glad at the time I’ve spent. Objective-C is rather nice (apart from the lack of garbage collection—refcounts make me nervous). And Interface Builder is the nicest GUI builder I’ve yet seen. Or at least it’s the only one that didn’t make me run away screaming.

Update: Looks like I missed JavaScript OSA. But that doesn’t look like it’s been updated in years.

• JavaScript::JSLint 0.04, which is just renaming from Lint to JSLint to more accurately reflect where it’s come from (pointed out by Matthias Miller).
• subatom 0.07 which switches from the baroque XML::Atom api to the much nicer XML::Atom::SimpleFeed (thanks, Aristotle).
• subatom 0.08 because I am a doofus and left a warn statement in.

(aside: everybody please read ‘Considered Harmful’ Essays Considered Harmful. Thank you)

The post he links to brings up a number of valid points about where valid uses of JavaScript can be flagged up by JSLint. This is perfectly reasonable. For example, you rarely want to use eval() in JavaScript, but when you need it, it’s the only way to do what you want. In that case, JSLint provides a flag to disable the warning.

But the real point is that you can’t just blindly follow results from a tool for what are ultimately stylistic issues like these. You have to use your knowledge as a programmer to interpret the output and agree / disagree with each point as appropriate. The purpose of JSLint is to flag areas that might be of concern, or perhaps be liable to bugs. It’s not saying “this is a bug, absolutely, for sure”.

One thing which might be useful (although I have no idea how easy it would be to implement) would be to be able to specify hints in the same manner that you could for C lint. There is already one example (declaring external definitions), but there could be more.

Whilst I am sure that it has it’s flaws, I’m extremely glad to see tools like JSLint being made available. Analysis tools like these help to move JavaScript from being “toy for websites” to “useful programming language”.

Now all I want is a JavaScript equivalent of perltidy…

I also fixed a problem where I was covering up errors when the lint couldn’t do anything more (e.g. nested comments). After my mailing Douglas Crockford about it, he kindly pointed out that this was mentioned in the comments. I’d entirely missed it. Ah well. Anyway, it now returns a “cannot proceed” message.

Update: after spotting something rather stupid, I’ve now uploaded JavaScript::Lint 0.03 instead.

So now I’ve wrapped up JSLint into a small command line tool (and Perl lib), JavaScript::Lint.

It’s fairly simple at the moment. I plan to add support for the options in jslint soon.