Why we use coffeescript

Years ago, I was a PHP developer. I used to build apps and and websites for my classmates and communities I was part of. When I get my first job (a non technical one), I was missing programming. So, I started a webradio project called Dolebrai. I worked on it with friends who were the maintainers of Savonet/Liquidsoap a sound streaming framework. When I submit my first version of the website, David, one my two mates, was satisfied by the site but not by the code. He didn’t approve the choice of PHP as programming language and suggested me to look for alternatives like Python or Ruby.

Disclaimer: This text was originally posted on our previous mailing list as an answer to a contributor who was asking why we choosed Coffeescript as our main language. I decided to publish it after a recent discussion on Hackernews about someone who left Coffeescript. The last two paragraphs are more related to Cozy.

I was surprised because David was an OCaml advocate. At first, I was quite angry because changing language meant to rewrite all the code. Then, my curiosity pushed me to google for Python or Ruby ways of coding a web application. I quickly found two uprising frameworks Ruby-On-Rails and Django. It took me weeks to decide which one to chose but I finally opted for Django. It was my first experience with a full featured framework. I rewrote the website with Python. I really enjoyed it. And of course, it quickly became obvious that I won’t be able to code a web app without a framework anymore. I dropped PHP from my toolbox too. We were in 2006.

Then I quit my job, at the same time I stopped my webradio project and went back to programming as a professional activity. Here I coded in Java. I was a front-end developer and spent most of time writing GWT code (so almost no Javascript). I was found of object-oriented programming and I enjoyed to build sophisticated classes with Java and to have a lot of well organized files with complex deployment. Then I discovered and read two books: the “Laws of Simplicity” and “Getting Real”. To make it short, they tell you that good stuff doesn’t mean complex stuff, that you should focus more on the useful part than trying to build a masterpiece of art. These readings made me understand that my code was over-engineered: it was hard to maintain and didn’t encourage my peers to collaborate on it. It was already dead code.

Parallelly, I kept following programming blogs and new open source coolness. I decided to start a new side project to have a taste of those new technologies. That project was Newebe, a Python-based distributed social network. So, I went back to Python and still choosed Django as a framework. But Django was over-featured for what I wanted to achieve with Newebe. I quicky changed for Tornado, an asynchronous and lightweight web framework. Once done, I coded quicker than ever and shipped the easiest to maintain code I ever wrote in my life. Once there, I realized that my previous over-engineered stuff was partly due to the technology I choosed: Java. Java pushed me to write a lot of things: long class, types, punctuation, access keywords, etc. While Python made things clearer and lighter. Plus, Tornado made the architecture simple and consistent. Another technology choice that had a big impact on my code quality.

Then I started to write the front-end part more seriously. At the beginning I was satisfied with Javascript. I started to make a MVC architecture. Then I looked for an existing MVC framework for JS. I experimented them to finally select Backbone because of its simplicity. It provided me with what I liked: a frame to organize well the code without too much magic or constraints.

Jeremy Ashkenas, the Backbone author, is the Coffeescript author too. So by reading Backbone tutorial, I discovered Coffeescript: a programming language with a light syntax, code that looks almost like pseudo code, indentation-based blocks, etc. No need to say I loved it at the first glimpse. Leaving GWT for Backbone and Coffee gave me the same feeling as described before. Building better code quicker is always satisfying. We were in 2011.

While enjoying these tools, I noticed that the Node.js community was super active and build great libs for web development. So when we started coding Cozy, I proposed to Benjamin to make it with Node and Coffee. He agreed and we built the first shapes of what Cozy is today. We faced some drawbacks about code transformation, but the trade-off was still good: we gained a lot of time with development and maintenance.

When the developer team grew with the arrival of Zoé, Joseph and Romain we were glad to see that they were able to code on day 1 (despite the fact they didn’t knew Coffeescript before). One week later they were fully operational. Of course, they had a good computer background but I’m sure that CS helped a lot. Months later, they all agreed that they had more fun coding with CS than with JS. They enjoyed doing better programs quicker. Our choice was validated by the fresh look of young graduates.

To not feel dogmatic and make contribution less scary, we ported all our tutorials in Javascript. But for the core parts and our main apps we have kept Coffeescript. CS and Node.js fit perfectly with our requirements which are:

• Building light web applications and modules.
• Building easy to maintain and reusable software.
• Building software that makes collaboration easy.
• Having fun by writing elegant and concise code.

We follow these principles as much as we can: our apps are accessible and simple, our libs are small and don’t require more than 10 minutes to be learned, we kept our data/service layer easy to use, our app deployment is described by just a light manifest, security features are based on simple permissions, etc.

To conclude, I will ask you a favor: go further than the language choice and embrace the full philosophy behind the project. Our goal is to build easy-to-use and interoperable web apps. Softwares that can be understood by any developer, that are remixable and that you can share with anyone. It’s our recipe to make the web a better place. This is what matters. Whatever language we use, it will not change.