> It wasn’t just fancy HTML we had to build; it was a port of a
> graphic- and animation-intensive Flash app, with the polish
> intact,1 and it had to work on iOS. It had to work on IE7.
> It had to work on Android 2.1 on one of the clients’ phones.
> And we had six weeks. We did the maths and figured that at
> twelve hours a day, six days a week for six weeks, we might
> just sneak in.
> [...]
> There were also three levels of stakeholders above us, with
> different priorities, and constantly shifting (and always
> growing) specs cascading down from above as the site took shape.
>
> After some discussion with my ‘if I get hit by a truck’ backup
> developer, I decided to add CoffeeScript to this, despite no
> real experience with it.
Then you're a brave, brave man. After this intro, I fully expected to hear a disaster story of missed deadlines and feature cuts ... not a successful project and a Super Bowl launch.
I think it goes without saying that "on deadline" is probably not the best time to learn a brand new JavaScript dialect. I'm relieved to hear that it all turned out for the best.
You mention that you're thinking of adding an explicit validation step -- great idea. For CS & JS (which can be compiled and validated quickly), even better than having it run when you build is having it run every time you save the file in your text editor...
A DHH type would've slammed this guy for being not giving the language its due, you are way too nice J!
After working hours and hours on a Coffeescript framework, I can say thinking in Coffeescript finds a different place to exist than Javascript or any other language. I particularly made use of object and array structuring, destructing.
Given no tooling that I liked in the Java realm I work in, I made my own compiler using Rhino and Coffeescript.js.
Within a month I had accomplished what would've taken me 3 months in Javascript. Within two months I had rewritten my original framework to Coffeescript paradigms that were emerging from the code AND I was adding features to my framework rapidly. My Coffeescript code came in about 55% of comparable Javascript. In framework version 1 it was about 75% of comparable Javascript.
My biggest critique of the article is the process. The author picked a tool he are not familiar with, probably produced sub-par code, and then for the next project aims to pick something else they appear to be equally unfamiliar with. That's great for padding the resume and getting the next gig, but terrible for producing high quality.
This is what I've been spinning in my head: Why. Why? Why would you choose such a high-stake, broad-scoped project as the time to use brand new tech which you have no experience with?
It's fantastic that everything worked out in the end, and the CoffeeScript pain point analysis is nice to have so clearly put, but still, my mind is fixated on that original "Why?"
"Brave" is far too kind. This is the kind of project nightmares are made of. Unless the pay was completely off the charts or I needed the work badly I wouldn't go anywhere near this type of project.
To reply to you and jashkenas, we weren't completely delusional. Sure, the project was big and tight, but we were pretty confident that we could nail it; none of the particulars were new, just the scale and the timeframe.
There was never any question of "can we actually do this?", just "can we do this in time?" Hence picking a tool that looked like it might offer some shortcuts. Yeah, it was a hell of a lot of work, but that was always going to be the case, and I accepted the project on those terms.
(My post perhaps came across as more extreme than the reality. We delivered. The site works. The code never got to 'unmanageable'. Given the opportunity to refactor this particular site, I'd leave it in Coffee, although I'd rework the build and deployment process.)
I think it goes without saying that "on deadline" is probably not the best time to learn a brand new JavaScript dialect. I'm relieved to hear that it all turned out for the best.
You mention that you're thinking of adding an explicit validation step -- great idea. For CS & JS (which can be compiled and validated quickly), even better than having it run when you build is having it run every time you save the file in your text editor...