Goodbye JavaScript

The JavaScript server code for Turtle Paint is becoming increasingly difficult to manage. People had warned me beforehand, but there’s no teacher like first-hand experience. The problems in a nutshell:

  • Immaturity. Often, there are five different Node.js libraries that do approximately the same thing, but all of them are buggy and none do it exactly the way you’d want.
  • Documentation. Nonexistent for most Node.js modules; most just provide one or two canonical usage examples. You could argue that I should simply read the source, but that is often difficult if you don’t have the high-level picture of how things fit together.
  • Callback spaghetti. For instance, the way I’m importing a word list into the MongoDB database backend takes no less than seven levels of nested callbacks: create database connection, open database, drop collection, create collection, open file, read lines, insert data. When done reading, open other collection, update word count. When written like this it looks straightforward, but in code, each action is a new level of nested callbacks. There are libraries like flow.js that make this a little easier, but they mostly remove indentation levels while not fundamentally changing anything. I like to write event-driven code when it makes sense, but being forced to use it for everything is a pain.
  • Difficulty of event-driven programming. It gets really difficult to tell what gets executed when. For instance, I had a bug where I opened a file and wanted to read it line-by-line in an event-driven way. I knew how many lines the file had, but the code consistently kept reading fewer lines than that. The cause? After verifying that the file existed by having opened it successfully, I opened a database connection. But while doing so, my file object already started streaming out read events, even though no event handler had been hooked up to it yet! This caused the first few thousand lines of the file to be ignored. As the event handler needed an open database, there was no way to hook it up earlier. The “fix” was to open the database first, then open the file and synchronously hook up the data event handler.
  • Tooling. With a language as tricky as JavaScript, a proper linter is essential. The popular solution, Crockford’s JSLint, is too opinionated and just gets in the way; for instance, it wants me to declare var i; at the top of the function if I use i as a counter in a for loop, K&R C-style. Some such nonsense can be turned off, but not all. JSHint is better in this respect, but has other problems. Both struggle with unrecognized global variables that Node.js provides.
  • Syntax. It matters. Too many function objects make me go dizzy.

I could have switched to CoffeeScript, which is a Ruby-inspired language that is translated in a fairly straightforward way into vanilla JavaScript. However, it would mess up stack traces from Node.js because those refer to the compiled JavaScript code, not the CoffeeScript source.

Therefore, I decided to rewrite the server in Ruby. The client will obviously have to remain JavaScript, but it is pretty straightforward and mostly does DOM manipulation; all the logic lives on the server side.

I’m planning to use Sinatra for serving static files, and Cramp (built on top of EventMachine) for the game logic. This will still be event-driven code, but only where it makes sense, and hopefully Ruby syntax will make it more pleasant to use. Cramp supports WebSockets out of the box, assuming one uses Thin or Rainbows as the HTTP server.

For older browsers, I might use the Flash fallback of web-sockets-js, or I could use But as I don’t like Socket.IO very much either (feature creep, bad documentation, and new bugs every release), it’ll probably be the former. There won’t be a “polling” fallback for browsers that support neither WebSockets nor Flash, but I think I can live with that.

It’ll be interesting to see how the JavaScript code compares to its Ruby counterpart.



Mark IJbema

2 years, 9 months ago

Small point, I don’t agree on the var i declaring on top being nonsense. Since if you declare it in a loop, it actually is available from the top of the function, so better declare it there, so that your code matches what javascript does with it. Small detail, but good to know imho (I used to think this was silly too, but it really isn’t ;) ). Have fun with Ruby :)


Marten Veldthuis

2 years, 9 months ago

And you could always use some service like Pusher when it gets too hairy to deal with the peculiarities of browsers yourself.



2 years, 9 months ago

Have you tried Go? I dunno - I’ve been playing around with the language and really been enjoying it, and it was originally designed specifically to write servers with.

Here’s an example of a “Chess roulette” game:



2 years, 9 months ago

And some explanatory slides:



2 years, 9 months ago

I’m ashamed to admit that I didn’t even consider it. Last time I looked at Go, there were some serious GC issues, but supposedly that’s better now. Would also need a MongoDB driver, probably exists.


Job van der Zwan

2 years, 9 months ago

You mean this?

If the server runs a 64-bit kernel, there are no problems.

In 32-bit, there are some tricks to avoid the problem, the easy ones being to use slices instead of arrays, and calling runtime.GC() more often to prevent the heap from growing into pinned pseudo-pointers.


Job van der Zwan

2 years, 9 months ago

Great, managed to do that link exactly the wrong way around…





(Markdown formatting accepted):

Copyright © 2011, Frozen Fractal. All rights reserved.