The unbeauty of JavaScript

Every Serious attempt I’ve made at liking JavaScript has almost always been put to an end by it’s messy syntax. About A Year ago, after yet again getting involved in a project where JavaScript was needed I thought to myself why anyone hadn’t invented a sane cleaner JavaScript syntax precompiler, there turned out to be a couple of them that looked good promising.

I Have in recent years professionally mostly been working with Java for any larger projects since I am quite comfortable with how that platform works on a lot of levels. On top of that I have also been trying out smaller projects using stuff like python (django, fabric and writing utilities), haskell (xmonad), groovy (gradle) and ruby (rails, jekyll).

Having some experience in that mix of languages plus some analysis in mind I very quickly settled on CoffeeScript.

Thoughts on code generation and CoffeeScript

There exists many editors and IDEs with carefully designed language support that somewhat helps the situation. For every fancy editor feature you use the editor itself moves closer to becoming a kind of keyboard shortcut oriented DSL or code generation tool that many times just makes up for some inefficient language syntactic expressions. My history with code generation tools is mixed, I’ve worked with really good ones while others have been painful to use. From my experience, a DSL/cross compiler usually needs to either provide an significant productivity gain and/or match the target platform(s) in an intuitive way.

CoffeeScript maps very close structurally to JavaScript and adds only some small things on top of it. This makes it easy to do things like debug generated java script code in the browser while effortlessly mapping the generated code to the CoffeeScript source files manually in my head (it’s a quick learning curve). By being light on extra language features CoffeeScript also avoids adding any default run time libraries or other dependencies to projects using it, it’s just JavaScript. It took between one and three weeks before me and my programmer project mate at work were almost fluent in writing CoffeeScript and had no problems intuitively debugging the generated JavaScript code.

An Simple example

A very simple comparison of a trivial function.

JavaScript

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// Log an error to the console and defer the displaying of
// an alert until the end of the current execution context.
var logError;
logError = function(message, level) {
  console.log("error: " + level + ": " + message);
  if (level > 10) {
    setTimeout((function() {
      alert(message);
    }), 0);
  }
};

// Test the alerts
logError("an unimportant error");
logError("an serious error", 100);

Translated to CoffeeScript

1
2
3
4
5
6
7
8
9

# Log an error to the console and defer the displaying of 
# an alert until the end of the current execution context.
logError = (message, level) ->
      console.log "error: #{level}: #{message}"
      setTimeout (-> alert message), 0 if level > 10

# Test the alerts
logError "an unimportant error"
logError "an serious error", 100

Not sure what to think?

Check out coffeescript.org where you can try CoffeeScript out in your browser.

UPDATE: I recently found a panel interview article, Should you learn CoffeeScript?. The author of CoffeeScript and others have their say. It might help you decide if CoffeeScript is something for you.

UPDATE: I have moved on (2012-02-02) After a short test run in November/December 2011 I finally migrated to Etherpad Lite which seems work much better for my set up. I usually have less than 100 unique users per week and the stability and availability is fine. EtherPad Lite uses less RAM and the CPU load is negligible.

Among mango

I have been hosting an collaborative document editing service using etherpad on mango.medeltiden.org since a couple of weeks after it was open sourced by google. I checked out the google code mercurial repository, made some minor fixes to make it work in my environment and since then it has been running 24/7 without any major problems.

Yesterday I decided to upgrade and install the new Debian packaged etherpad that has been on my to do list since forever.

Creating the package

After looking briefly at the Debian package available at etherpad.org I concluded that I needed to make some minor modifications to make the upgrade.

1. I Forked the etherpad.org repository
2. Created a Ubuntu-java6 branch in my fork, changed the debian package dependencies to support any java 6 version such as open-jdk in an Ubuntu environment.
3. Found a couple of small bugs (1,2) in the Debian packaging
4. Diffed my changes to the original source release to ensure that all fixes where covered in the etherpad.org version. (they were)
5. Created a private git branch for mango that holds my theme changes and pushed that to a private gitolite hosted repository since it is of no general interest.

Thats it, easy and smooth.

For the love of Git(hub)

I can still get silly amazed how streamlined git and github can be. I never got this feeling with subversion while working with it daily for almost 8 years. Git never gets in the way and there is a trick for almost anything if you need it.

While Darcs and Mercurial also has their strengths Git feels like something that might be the revision control system v0.9 for me.

Future of mango/etherpad

While etherpad is a great tool and very stable it is a bit resource hungry, contains a bit too much of framework code which is largely unmaintained. I am looking forward to testing out and possibly contributing to projects like etherpad lite or something similar. Of course data migration also needs to be supported for the sake of DATALOVE and the power of kopimi. Also remember to hate the police.

Instasearch is an eclipse plugin that indexes the workspace using lucene for fast immediate searching. Take a look at the

Screenshot

Installation

Install using the Eclipse Marketplace

Ack is a command line search tool that somewhat resembles the standard unix general search tool grep.

Ack is specifically targeted for searching source code. It’s generally more convenient to use than grep since it has an built in list of source code file types it knows and nice default highlitning.

Example search:

$ ack-grep glMatrix

Installation

The Ubuntu/Debian apt package name is ack-grep , install by typing

sudo apt-get intall ack-grep

For other operating systems and ways of installing, see the ack homepage.