A Daring Move:
Rewriting the Prototype from Java to JavaScript

The Gambit

This week we decided to rewrite the client prototype and change its run target. The prototype is not even done, and we’re already rewriting. This is usually taken as a bad sign in a project, but I think rewriting going to pay off. That’s the gambit.

I wrote the initial code in Java, and it was targeting the console. When the prototype was ready, I would send a JAR file to Andrew, and we could start work on refining and balancing game mechanics. Now the prototype will be in JavaScript, and the text output will be written to a <div> instead of a terminal. It’s the same basic idea, so why the rewrite? These are the pros and cons.

Pros

• Faster Playable Iterations
  I know there will be bugs that need to be fixed. And I know we’ll want to try different settings for the game. Making changes playable in the JAR means: building the JAR, finding it on the filesystem, sending it through email or Dropbox, and waiting for Andrew to download and run. Making changes playable on the web means hitting save and telling Andrew to reload the page.
• More Configurable Output
  Doing a console version was supposed to focus on game mechanics, as opposed to graphics, animations, UI, etc. Good idea in theory, but I ran into some problems.
  For example, there’s no universal way to clear the terminal in Java. Best thing you can do is check the OS at runtime and manually send the command: Runtime.getRuntime().exec("cls") for Windows, Runtime.getRuntime().exec("clear") for everyone else. But that works neither in the IDE output, nor in mintty. It’s not a huge deal to have infinitely scrolling text, but compare that to document.getElementById('id').innerHTML = ''. Advantage HTML.
• A Weak, Dynamic Type System
  This is something that usually drives me crazy about JavaScript, but this early on in the process, I can see the advantage. The server side code is changing everyday, and with JavaScript I can just take whatever JSON string the server sends back and start using the values. In Java, whenever the server sends back new data, I need to change class definitions, track fields that get renamed, parse String to int, etc.

Cons

• The Rewrite Itself
  The rewrite took about 2 days, and that time could have been spent on new functionality.
• A Weak, Dynamic Type System
  What’s an advantage in the earliest stages is also a drawback once the code starts getting a little complex. There’s no way to see what’s really in an object until runtime. This gets so much worse with 3rd party libraries. What’s in the jqXHR object, for example? The jQuery docs here are really frustrating. I kind of just want a list of member variables and member functions, and it’s easier to get that from Chrome’s Dev Tools than from that documentation.
  A stronger type system lets a Java IDE provide most of this information, but I haven’t found one that can do the same for JavaScript. Maybe this is why people like WebStorm so much—I haven’t tried it. If it can do that, then it’s probably worth the $50. Anyway, </rant>.

Conclusion