Before joining this project I spent two weeks on another project helping them make a technology decision. This other project had a requirement for a sophisticated web UI. The choices were Flash or JavaScript. After helping with some spikes the team decided to use JavaScript. As this would be the first time anyone on the team would be using JavaScript, I made some recommendations. One of these was not to use CoffeeScript.

I was wrong.

It was a new project with a team of people who weren’t very familiar with JavaScript and certainly had not written a large JavaScript application. I felt that CoffeeScript would be another new thing for what until very recently had been a Java team. It would be better to first learn JavaScript; understand that and then learn how CoffeeScript can make the language better.

After that short consulting gig, I started on this project on the following Monday. This was another sophisticated JavaScript UI application. But it was already about two months into development. This project had already decided not to use CoffeeScript, for similar reasons as I’d gone through on the previous Friday. It was like jumping forward in time two months. More than anything else, with the amount of JavaScript code we had, the syntax was just agony. It simply made the code harder to read. This may sound like a small detail, but I believe very strongly that code needs to be readable by humans above everything else. JavaScript’s syntax is simply woefully inappropriate for the style of programming the language is otherwise very tuned for.

As I mentioned above, we used underscore.js pretty heavily. This encourages a lot of anonymous functions passed as parameters, something that reads very nicely in Ruby. In JavaScript, a simple loop to lowercase every string in an array reads pretty painfully.

var keyNames = _.map(recipientNames, function(name) {
  return name.toLowerCase();
});

By the way, the glyph }); is henceforth known as the coffee-break.

The absolute bare minimum for a lambda is function() { return; }. That’s 19 characters! 19! Here’s the same code in CoffeeScript:

keyNames = _.map recipientNames, (name) -> name.toLowerCase()

That is one plausible line. Yes please, can I have some more? This may seem like a small detail on its own. It’s just syntax, you say. You may disagree with my opinion that syntax is critical. Allow me to offer another example from this project. A couple of us are Ruby programmers, and fans of the very declarative style of test that is possible in RSpec, using let.

describe "an account" do
  let(:subject) { Account.new(:balance => balance) }
  describe "positive balance" do
    let(:balance) { 100 }
    it "should allow withdrawals" …
  end
end

The JavaScript unit testing library of choice, Jasmine doesn’t (yet) include any equivalent of this. So I whipped something up pretty quickly to allow the equivalent:

describe("an account", function() {
  define({subject: function(ctxt) { return createAccount({balance: ctxt.balance()}); }}, function(ctxt) {
    describe("positive balance", function() {
      define(ctxt, {balance: function() { return 100; }}, function(ctxt) {
        it("should allow withdrawals", function() { …; });
      });
    });
  });
});

There are two problems here. Firstly, JavaScript doesn’t have instance_eval or method_missing so you can’t decorate a lexical scope before passing it downwards, hence explicitly passing down the ctxt parameter. Actually, while the lack of method_missing is a real pain, I think instance_eval is no great loss and I would happily write much, much code in a language that doesn’t allow libraries to mess with name bindings quite so liberally.

Secondly, the sheer noise of the JavaScript syntax is incredibly painful. Here is the equivalent, translated directly into CoffeeScript.

describe "an account", ->
  define
    subject: (ctxt) -> createAccount balance: ctxt.balance()
  , (ctxt) ->
    describe "positive balance", ->
      define ctxt,
        balance: -> 100
      , (ctxt) ->
        it "should allow withdrawals", -> … 

The most interesting thing from this conversion, to me, is that it shows that the double-nesting of defines and describes is actually pretty unclear. In my copious spare time I’m working on a better implementation of that define() function, in the hope of getting it added to Jasmine. If I’d been staring at that second version throughout the project I would have started down that path earlier.

But the better syntax is not everything; the other features in CoffeeScript, like list comprehensions and default arguments are Good Things and would have been very nice to have.

The application is a mobile web app for a customer who already has a number of native apps for iPhone and Android. All these apps use an existing set of services to access the core data. Our app used JQuery Mobile and Underscore.js as the only libraries. For testing, we used Jasmine and cucumber.

Originally, I wanted to post this as a single post, but it go long. Very long. Looking back on our project, there were four things I’d like to try doing differently.

• We didn’t use CoffeeScript for what felt like very good reasons at the time. In hindsight, this was a mistake.

• Writing functional tests for a pure JavaScript application is a different problem requiring different solutions than a typical web application.

• Your JavaScript application is going to end up as a very sophisticated GUI application, with more complex state and flow management than most typical web applications. Consider your use of models and controllers very seriously.

• Web applications have long had to deal with the Back and Refresh browser buttons. A single page JavaScript application adds some new wrinkles. But I think that HTML 5 also includes some neat solutions.

As I get my posts written, I’ll update the above with links.

In this conversation most people point out that URL shorteners have proliferated because of the popularity of Twitter. Kottke has now proposed that Twitter run a URL shortener of their own. Which seems eminently sensible, given the current state.

I’ve got a different suggestion: Twitter should actually let me use the <a> anchor tag in my tweets. Just like I’ve been doing in HTML for as long as the web has been around. That is, the URL in your tweet should not contribute to the number of characters in your tweet, and it should also not be visible. Instead it should be attached to a word, phrase or perhaps the entire tweet. This should be optional: without markup URLs pasted into tweets should maintain the status quo.

Of course, no other forms of HTML markup should be supported: linking would be enough. The Twitter web site and desktop and custom phone clients would have no problem rendering a link. Only SMS clients would have a problem, and for these perhaps the fallback is to shorten the URL using Twitter’s own URL shortener and insert that into the tweet. SMS clients may not be that common for much longer.

Assuming Twitter allows specific parts of the tweet to be marked up, then I suggest Markdown syntax for the link. This recent tweet would have been typed out as:

I unplugged every landline phone in our office
because of [marketers](http://sethgodin.typepad.com/seths_blog/2009/04/poisoning-the-well.html) (via @misswired)

Which would have appeared as:

I unplugged every landline phone in our office because of marketers (via @misswired)

Which is what I was actually trying to say.

Of course allowing link markup like this is going to be very popular with spammers. Two counters:

1. Twitter should include rel="nofollow" on links when rendering – as they already do.
2. Don’t allow targeted markup like this, instead allow the entire Tweet to be marked up – only one link per tweet. The disadvantage with this is that sometimes I want more than one link, and the appropriate rendering is not obvious.

Both targeted markup and one-link-per-tweet have advantages and disadvantages, I’ll leave it up to Twitter to choose between them. But please, give me back my <a> anchors.