Why CoffeeScript?

138 views
Skip to first unread message

Terrycloth

unread,
May 12, 2014, 1:15:48 AM5/12/14
to cozy-...@googlegroups.com
I'm new to programming, but excited about Cozy Cloud and trying to figure out how I can get some more practice coding, and eventually contribute to this project.

I think I already know the basics of JavaScript, so Cozy seemed all the better when I found out it was based on Node.js -- until I noticed that a lot of the code is actually written in CoffeeScript. Now, I've only read a little about CoffeeScript, not looked too much into actually learning the syntax, but I don't really see the point. CS has simpler syntax than JS, but CS transcompiles to JS, and working backwards from error messages in the compiled JS to the source CS adds complexity to the debugging process. Is this trade-off really worth it? Don't developers usually spend more time testing and debugging code than actually writing already?

I've had it recommended to me that I really get to know vanilla JavaScript before worrying about starting CoffeeScript; if I have to know JS anyway, I'm not sure how learning a whole new syntax helps.

I've read a few articles by users of CoffeeScript, and most of them didn't seem to like it either. Clearly, someone at Cozy Cloud likes CoffeeScript, though. Would you mind sharing why you chose to use it?

Joseph Silvestre

unread,
May 12, 2014, 2:55:05 AM5/12/14
to cozy-...@googlegroups.com
Hello Terry,

This is a good question! You are right: developers spend lots of time debugging and testing. But they also spend lots of time reading it (and writing) which is where Coffee simpler syntax shines in my opinion because you can almost read it like natural language. Note that easy code to write and to read tends to lead to cleaner and simpler code, and I think a simple code can be found less buggy than a complex one (at least, it's easier to debug it).

The debugging complexity you talk about has been "fixed" thanks to source maps that allow to see from your browser which line of your Coffee code is involved. They also allow to do the same to minified javascript files.

Also, another cool stuff about Coffee (or others compiling-to-JS languages like TypeScript) _yet less used_  isn't Coffee itself, but the fact you need to compile it on the fly, allowing some other building check and stuff like style checking and automated tests. I may add other languages like LiveScript takes more benefit from this step since it provide strong typing out of the box. We are using brunch to do the building but you may find relevant to check other similar tools famous tools: Grunt and gulp.

Keep in mind though, that in the own words of Coffee's creator, "Coffee is just JS" so if you want to learn something, learn JavaScript first because in the end that's what you are writing. Coffee is just syntactic sugars above JS.

I hope I gave you good insights of compiling-to-JS languages (again, there are others and I like the idea of strong typing in TypeScript. You can find a list here https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS).

Cheers,
Joseph.

James Mills

unread,
May 12, 2014, 1:26:22 AM5/12/14
to cozy-...@googlegroups.com
Hi Terry,

These are all good and valid (IHMO) points. I have myself struggled to understand why anyone in their right mind would choose to use a language that is just a frontend to another language. I mean most languages are in fact just this; however if you take the example of Python for example you don't end up debugging Python bytecode or even C for that matter -- You debug Python.

The difference here is that CoffeeScript does not compile to anything but translates to JavaScript. So in the end you are right; you have to debug JavaScript.

As far as Cozy Cloud's implementation language(s) -- I was not aware it uses CoffeeScript? Frank can you elaborate on this?

cheers
James

Joseph Silvestre

unread,
May 13, 2014, 7:49:16 AM5/13/14
to cozy-...@googlegroups.com
Again, thanks to source maps you will find yourself debugging Coffee code, not JavaScript; even if you are right that Coffee doesn't strictly compile into JavaScript, it is processed before runtime (I believe this is where the language abuse comes from) and the source maps will tell the browser (or Node) how to find the proper Coffee line based on the JS error at runtime. There are other good arguments against the use of Coffee or any similar tools, but this one hasn't been valid for a while now. I think the best of them is "I don't like it" because the community has been working hard on fixing the objective ones.

About Cozy, most of the code is JS written in Coffee (except the indexer that is in Python and very very rare cases of full JS implementations...I actually can't even remember a name^^).
We do one very bad thing though: we commit and push the sources and the built version of our files because the platform isn't good enough to do it by itself right now. Obviously this is something we will change in the future!

Cheers,
Joseph.

Frank Rousseau

unread,
May 15, 2014, 6:03:48 AM5/15/14
to cozy-...@googlegroups.com
Terry don't worry, Cozy is fully compatible with Javascript. If you want to contribute to Cozy, you can build a web app written with JS.

About the Coffeescript choice, I have no non-emotional stuff to add, Joseph explained everything. Now if you want to know more about how we chosed Coffeescript for Cozy, have a coffee and read the full story.


Years ago, I was a PHP developer. I used to build apps for my classmates and websites for communities I was part of. When I get my first job (consultancy stuff), 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 and suggested me to look for alternatives like Python or Ruby (I was surprised because he was an OCaml advocate). At first I was quite angry but finally I started to google for Python or Ruby ways of coding a web application. I quickly found Ruby-On-Rails and Django. It took me weeks to decide which one to chose among them but I finally opted for Django. So I started to use a web framework and code with Python to build my the website. I really enjoyed coding with Python and it 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 buildsophisticated classes with Java and to have a lot of well organized files with complex deployment. Then I discovered the "Laws of Simplicity" and "Getting Real". Two books that tells you good stuff doesn't mean complex stuff, that you should focus more on the useful part than trying to build a masterpiece of art. I understood that my code was over-engineered: it was hard to maintain and didn't encourage my peers to collaborate to 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 (in fact, mostly to learn Git). It was Newebe, a distributed social network. So, I went back to Python and choosed Django as a framework. But Django was over-featured for what I wanted to achieve with Newebe. I changed for Tornado, an asynchronous and lightweight web framework for Python. 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 chosed : 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. Again, the technology choice had a big impact on my code quality.

Then I started to write the front-end part. 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. Then I selected Backbone for 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: light syntax, code looks almost like pseudo code, blocks are indentation-based, etc. No need to say I loved it. Leaving GWT for Backbone and Coffee gave me the same feeling as described before: I built better code quicker. 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 graduate.

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 kept Coffeescript. Except the fact hat Node.js consumes too much memory, CS and Node.js fits perfectly with our requirements which are:

1) Building light web applications and modules.

2) Building easy to maintain and reusable software.

3) Building software that makes collaboration easy.

4) 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.

If you get interested into Cozy, 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.

Regards,

Frank

Terrycloth

unread,
May 16, 2014, 11:40:35 PM5/16/14
to cozy-...@googlegroups.com
Thanks for sharing that story, Frank.

I guess you've won me over -- I should at least give it a try. I've been getting a lot of use out of the Cozy Notes app, but Notes is a little hard to use on mobile devices, so I thought my first attempted contributions might be to help with that somehow. I'll need to study a bit of CoffeeScript first, though.

I'll start looking through the Cozy and CoffeeScript documentation, and I can always look up other tutorials. But what was your favorite resource for learning CoffeeScript?

Terrycloth

unread,
May 17, 2014, 12:35:46 AM5/17/14
to cozy-...@googlegroups.com
...Or did you know enough programming languages by then that it didn't take long to pick up CoffeeScript?

Frank Rousseau

unread,
May 17, 2014, 11:25:26 AM5/17/14
to cozy-...@googlegroups.com
Hi Terry,

 I'm glad hearing news about you and your Cozy Notes usage! I use it a lot too and I agree that there is place for improvements.

About Coffeescript, here are three resources that could help you:
- The offcial website, it's where I started:
http://coffeescript.org/
- The Little Book on Coffeescript, it's where I improved my coffeescript skills: http://arcturo.github.io/library/coffeescript/
- The Coffeescript Cookbooks is where I found answers to many question: http://coffeescriptcookbook.com/

You have a lot of code exemple too in our Github repositories.
https://github.com/mycozycloud/


About the mobile mode, I think it will be mostly a "responsive design" issue. It could be solved by modifying CSS.
https://github.com/mycozycloud/cozy-notes/blob/master/client/app/styles/note.styl#L360
https://github.com/mycozycloud/cozy-notes/blob/master/client/app/styles/note.styl#L360

(Don't be afraid by the syntax, it's just CSS without semi-colons and braces).

What do you think about it?

Regards,

Frank

Terrycloth

unread,
May 17, 2014, 10:26:04 PM5/17/14
to cozy-...@googlegroups.com
Yeah, I knew making the Notes app design more responsive would probably be mainly a CSS issue. But I'd like to get my head around how it works at a basic level. Maybe then I'll figure out other things I can do too.

The CoffeeScript resources look great, thanks. I'll be perusing these over the weekend.

Terrycloth

unread,
Jul 11, 2014, 8:04:36 PM7/11/14
to cozy-...@googlegroups.com
I'm still getting the hang of JavaScript/CoffeeScript -- but I feel pretty good about HTML/CSS.

So I'm trying to figure out how I should edit the CSS for the Cozy Notes app. There aren't any complete HTML files in the git repository, because apparently all the content is dynamically generated, right? I thought to try saving a copy of the web page from my cozycloud.cc account, but this generates a CSS file different from the app.css file in the git repo. And copying app.css from the git repo to saved web page files completely breaks the layout.

I'm used to workign with static HTML files, or else working with something more like WordPress. Do I need to build the Cozy Notes app before I can edit the CSS?

Frank Rousseau

unread,
Jul 13, 2014, 8:41:47 AM7/13/14
to cozy-...@googlegroups.com
In the Cozy Notes app, we write our CSS with Stylus (it's like CSS without semi-colons and brackets). It requires a build process too. Basically, that means you should run an application assembler each time you make a modification. The assembler we use is Brunch. To use simply do the following

$ sudo npm install brunch -g
$ cd client
$ npm install
$ brunch w # This line watch for every modification: it runs the assembly process every time you change a file

Then refresh your browser, you should see your changes!

Here are related resources:
http://learnboost.github.io/stylus/
http://brunch.io/
http://cozy.io/hack/getting-started/learn-single-page-app-way.html

Frank
-- 
Frank Rousseau
skype: frank.rousseau.cozy
twitter.com/mycozycloud
github.com/mycozycloud
Reply all
Reply to author
Forward
0 new messages