The Future of JS Dev Tools Is The Parse Tree

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.

Admitted to the U of MN

Warning: personal entry.

Just an update on the college post a while back. I applied to the U and just learned that I was accepted for Spring semester, CLA Pre-CS. Not that it's a really hard school to get into, but for somebody with an academic background like mine it's one hell of an achievement. It was the last step in officially clearing my name and turning my academic career around. From here on, I have the same opportunity as a 'normal' student--even a good grad school is on the table, if I keep working hard.

Thanks to everyone for all the support.

Speedier Maven2 Webapp Development

Now that Soashable is ported to Maven, I want time savers because the change/compile/package/deploy/test cycle is way too slow. I did a bit of research and here's what I've found.

Some goals that are useful alone or combined:

war:inplace - copies all dependencies into the webapp source, including overlays, classes (made with 'compile'), dependencies. See caveat below.
javascript:inplace - copies javascript dependencies, the same way war:inplace works
jetty:run - runs the inplace webapp; scanIntervalSeconds of 1 makes rapid 'testing' possible

Using jetty:run in its own terminal requires no recompilation or packaging in order to see changes reflected in the running webapp, since it runs out of the source directory. A javascript:inplace or war:inplace in another terminal will copy any updated dependencies into place and work while the application is running.

This method cuts several seconds off of the change/test cycle, from around 10 in any case to 5 or less for dependency changes, and immediate for local changes.

The caveat is that it copies dependencies into src/main/webapp, which might confuse some junior developers or perhaps make svn:ignore invaluable. A slightly slower alternative is to use war:exploded and jetty:run-exploded.

Perhaps the best solution would be a hybrid resource resolver that first checks src/main/webapp and then falls back to the war:exploded target.

maven-javascript-plugin

I've been watching and trying out new development on this new Maven plug-in that's coming together after the recent threads [1, 2, Codehaus Proposal]. I've given a couple patches, and am becoming much more familiar with both it and the internals of Maven and the build lifecycle. I've spent more time than I would have liked encountering bugs and discovering that I’m an idiot, but the main developer has been extremely helpful. And all of this bug chasing has taught me a ton, so it hasn't been a waste by any means. As I told one of my colleagues: it’s the cost of early adoption; in the same way that some people lay down extra dough for the newest gadgets, I lay down extra time for the newest software.

I think this plug-in will be a great success and could potentially have a wide scale impact on the JS development community. The mature JS projects like dojo, scriptaculous and jsjac all have their own custom build scripts that do about the same thing as maven-javascript-tools. It will unify effort and allow people who like dealing with build tools to deal with build tools, and people who like dealing with libraries to deal with libraries.

I’ll be doing my part a bit more this weekend by creating some archetypes and maybe a screen cast if I’m feeling ambitious. I have to keep in mind that Soashable is my main project, and that I still have to do my homework. But man, does this project excite me!

It has the potential to raise confidence in JS and propel it to its place as a first class language. It’s been treated as one for quite a while now, but finally it will be able to walk the walk.