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.
3 comments:
I was originally planning to use the parser in Dojo's JavaScript Linker (AKA jslinker) for parsing JavaScript.
It looked like exactly what I wanted ... but I did a bit of testing and found some problems with the grammar. It would probably have been possible to fix these, but that got me thinking: how much has this tool been tested against real-world, production JavaScript code? After all, the readme file describes it as "alpha release ... meant for testing purposes only", so the answer is probably not much. I was really hoping for a rock-solid, well-maintained parser, so that bugs in the parser would be something I wouldn't have to worry about.
After that, I looked at Narcissus, but after my experiences with jslinker, I wondered whether I would have the same problems with Narcissus. How much has this been tested on real-world code? How well is it maintained? etc.
So in the end I decided to go with SpiderMonkey. Clearly, one of its advantages is that it has literally been tested against almost every piece of JavaScript code on the web, so you know that it's pretty robust. (Actually it's even better than that: if there are any bugs in SpiderMonkey, web authors would tend to avoid writing JavaScript code that triggers those bugs, so the end result is that you are unlikely to see such bugs for real-world code.)
If you're aiming for a more Java-friendly parser, I would tend to favor Rhino over Narcissus simply because Rhino seems to be more widely used and tested than Narcissus (although not as much as SpiderMonkey).
Have a look at dmdscript - The source should be pretty trivial to modify to generate a tokenized tree or parse tree..
I keep meaning to do something similar with the source as well. - It's alot more compact that most JS interpreters, and should be just as fast as the Spidermonkey one.
Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!
Post a Comment