Background

Some time during 2005 I ended up spending a couple of months working on a project for my employer (Guidewire Software ) that involved rapidly developing an application prototype that used a huge amount of client-side javascript. I can't really go into the details of what I was doing or why I was building it that way, but the upshot is that after a couple of months I had far more javascript (I forget how much, but something on the order of 8,000 lines not counting comments) than I've ever wanted to write and had come to be thoroughly frustrated by what I perceive to be some of the language's shortcomings. Near the end of the project I started working on this tool and had it functional enough to be usable on the last couple of javascript classes that I wrote before discontinuing work on it after I moved on to other projects.

No Language Holy Wars, Please

I'm going to delve into some language issues a bit to try to explain part of why I think the approach of writing javascript in Java makes sense and can be useful in some situations. I realize that a lot of people are zealots about this or that programming language but I try hard not to be one and to select the right tool for a particular job (though part of being a zealot, of course, is not accepting that there are different tools that are appropriate for different jobs). I'll be attempting to convince you that programming in Java is a more pleasant experience than programming in javascript, which hopefully shouldn't be a difficult task.

A Few Disclaimers

Guidewire develops enterprise software for property and casualty insurers, and we do so in Java for a variety of reasons (some technical, some non-technical). Working all day in Java means that it's the language I'm most familiar with, and my personal experience outside of Java is pretty much all in C and C++. I don't use scripting languages much simply because I don't do a whole lot of coding these days outside of work, and didn't really have much time back in school for any real side projects either. Thanks to that my brain thinks of code in terms of compiled languages and static typing, and I expect my compiler and my IDE to do a lot of work for me as far as catching simple errors, since it normally does (at least if you're in Java). As a result, I'm a bit biased towards thinking compiled languages are easy to work with, and as such can't be completely objective about a language like javascript.

Agile Development

Guidewire practices agile software development, which is pretty vague term, but pretty much any sort of agile methodology requires mercilessly and repeatedly refactoring code and writing a lot of unit tests. The agile development methodology is one of the things that just seemed painfully awkward in javascript, given how reliant that process (or at least my use of it) is on good refactoring tools.

The Problem

Some Half-Baked Philosophy About Types of Languages

This isn't fully thought out and has been stated better by other, more knowledgable people than myself, but I'll restate it again as it's important to why I think this tool is useful. Scripting languages are generally more productive to program in than compiled languages for a few reasons:

1. They have a more expressive syntax, allowing you to perform the same amount of work with fewer characters or lines
2. They have more powerful constructs, like macros or blocks, that allow you to do more work with less code
3. They have a more forgiving syntax, which takes out some of the overhead you incur in a compiled language
4. They usually have better built-in libraries for things like file manipulation, string manipulation, or networking
5. Iterations are a lot faster when you don't have to compile/restart/redeploy after every little change

I'm sure there's a few obvious things I've forgotten, and there are other meta-level benefits as well that come from having less code and needing fewer people to write it.

That said, there are actually a few things that Java still does better than any scripting language I'm aware of, most of which relate to the java IDEs:

1. Auto-complete and auto-syntax checking around class, field, and method names means you never write code that won't compile
2. Introspection and hardcoded interfaces make it very easy to poke around an unfamiliar library and see what that available methods and classes are
3. Complicated refactorings can be entirely automated (except for uses via reflection): you can move classes, rename methods and fields, add parameters to them, etc. with virtually no danger of breaking anything
4. On a large project with multiple people, the compiler helps prevent you from making changes that break other people's code that you're unaware of

I use IntelliJ IDEA at work, which is the best IDE ever made as far as I'm concerned, but even Eclipse is far ahead of anything I've seen done with any other language. I don't think any of these points are all that debateable: if you've ever programming in a good Java IDE and actually made heavy use of the refactoring support, you'll miss it when working in any other language, and while unit tests can sort of substitute for compilation on a small enough project, you'd need 100% test coverage in order to achieve the same level of confidence (plus they'll break just as often as the rest of your code). And since there's no refactoring support, when you do break things (which will be more often), they're harder to fix.

There are other pros and cons to any language, of course, so I'm just attempting to outline some of the basic ones that lead me to write this tool (or at least envision it).

Where Javascript Falls Down

Javascript is fine for what it was originally designed for (i.e. small bits of client-side logic on a web page), but it really starts to fall down when you start writing serious applications in it. It suffers from a serious tool shortage and doesn't have many of the benefits of other scripting languages. It does have some nice constructs in eval and closures, which come in handy in a lot of situations, but otherwise the syntax is basically the same as java, the syntax is (for me at least) forgiving to the point where it masks errors, and the built-in libraries are pretty minimal and not very cross-platform safe. On top of that, javascript has some pretty serious syntax deficiencies: while you can do classes there's no standard way to do so (and so no IDE will understand whichever one you choose) and any of them are pretty ugly to type out, there's no name space or packaging built in, scoping is counter-intuitive, there's no good way to control access to methods or properties, and (at least for me) expand-o properties generally cause a lot more trouble than they're worth.

As I progressed in my prototype work, I basically found productivity dropping linearly with the size of the code base due to the lack of decent tools: I had to do any refactorings by hand (including finding and fixing breakages after the fact), and so the time they took scaled pretty linearly with the number of usages of the thing I was refactoring. It also simply took me longer to write code in the first place because I couldn't ever code complete anything and so I had to constantly flip back and forth between classes (and docs, for things like the DOM) to try to remember exactly what the method or class names were, which is exacerbated by the lack of a compilation step. Those are complaints that I could make against any sort of scripting language, of course, but they're still annoying to someone used to a Java dev environment.

Solutions

Decisions, Decisions

I toyed with several solutions to the various problems: some of them could be solved by better frameworks like Prototype or Dojo that make OO features more useable, and some of them could be solved with some sort of javascript linter, or by marking up javascript in such a way that some other parser could come through and validate that everything would work as sort of an optional compilation step.

Why Not?

I decided to go a little further and see if I couldn't just leverage existing Java compilers and tools to do all that work for me: the compiler and the IDE would do all the work I wanted them to, and I'd just need to find some way to writing javascript using Java syntax. The basic syntax of the two languages is close enough, and you can add in enough hacks to allow you to write java code that will compile to a javascript closure, foreach, expand-o property, or eval statement. You can then refactor, auto-complete, compile, use the java class and packaging syntax, etc. to make sure the code stays clean and well-behaved, while still retaining the useful language features of javascript. Assuming the tool worked, the price would simply be the hacked-up syntax you'd have to use for the few things Java doesn't already support plus the time to run the tool, and it seems like you'd easily save all that time thanks to the improved tool support and clearer code.

After that the vision evolved a little more: what if you could have the java code behave exactly like the javascript code will, such that you could write (and refactor) your unit tests in Java as well? What if there was some well-documented Java interface for the DOM that had different implementations to correspond to different browsers, allowing you to automatically simulate running your code under different browsers? Etc. All nice hypothetical things to throw out there, of course, but some of them might turn out to be useful.

Since I'm a programmer I think that by definition I'm drawn to doing things that otherwise seem stupid or crazy, so I figured I'd give it a shot to see what happens.