Today I read an article from Sun research, entitled Using Javascript as a Real Programming Language. This obviously struck a chord with me, because it talks about exactly the stuff I've been pushing for since I started using it as a real programming language, a few months ago. Recently, I have been collaborating with a fellow from the Maven list who is building a Javascript packaging plug-in for Maven, and trying to integrate all the features from the late JSLibBuilder.

One point I've been touching on lately is that code coverage testing is the key to the sanity of any code base written in a dynamic language (same point applies to rails). While having 100% coverage can be fool's gold, it is a good measure of which code needs to be better exercised by tests.

My research has found me one complete tool for doing such a thing in Javascript: JSCoverage. It runs on the command line and instruments specified code to see which lines were executed. Basically what it does is add a Javascript function call on every other line, and when it is runs its special runner, it produces a report with annotated code coverage data. In unison with JSUnit, this gives the same sort of functionality as Java tools like Cobertura + JUnit (though, AFAIK it is only line coverage, not branch coverage).

I'd have liked to have integrated it with JSLibBuilder or javascript-maven-plugin, but because it is written in C (based on Spider Monkey), distribution would be hell. So I was doing some research to see if I could find an alternative Javascript parser that runs in Java or Javascript to port JSCoverage to, and came across a piece of gold: Narcissus, a Javascript interpreter written in Javascript. It is also, incidentally, based on Spider Monkey :). Easy porting of JSCoverage? I hope so. The reason a tool written in a Java friendly language is important is because it would be able to run during a Maven build, and be distributed through the central Maven repository.

Let me backtrack a little: the best Javascript code monkeying tools available right now are Dojo Shrinksafe and YUI Compressor (from a strictly 'safety' standpoint, others have achieved better compression ratios), for the simple fact that they are based on the Rhino Javascript engine, rather than relying on regular expressions and other potentially flaky methods to parse. Because source files are parsed and modified as they are serialized from a real Javascript parse tree, the engines produce 100% safe results. Naturally I wanted to see what else I could do with the parse tree available at runtime (cyclomatic complexity and other code analysis), but it turns out there is no public API for accessing the parse tree in Rhino(!), and no plans to implement one.

I only have to wonder whether anyone knows about Narcissus and there is a problem with it, or if it is just sitting there waiting to be discovered (it looks like it's been around since at least 2004). If Javascript is ever to be a first class language as people are treating it, it needs first class tools. This single tool is the key to getting so much more out of Javascript.

I'll surely be writing about this more.