YES:
It's not the time saved while writing the code that matters here -- although I do believe it adds up quickly if you work on a project that might occupy you for months or years and have invested the initial week of getting fully into CoffeeScript mode.
NO, it's the time saved reading your code time and again as you revisit your code-base over these months or years of refining your project going forward.
CoffeeScript's "easier writability" may be debatable, but it's its "easier readability" where it really shines. I can glance quickly at my way-fewer-lines of CoffeeScript and parse it much more smoothly than I ever could a curly C-style language. Maybe it's because I first started out in, boohoo, BASIC. But indented lines with no superfluous { syntax; decorators } just flow into my brain much faster.
If you're a fire-and-forget coder who writes line after faultless bugless line that you never need to revisit, review or simply recall and still get a meaningful composition of a program, app or site that isn't just a house of cards built on quick-sand or a simple batch job at the end of the day -- I envy you! In my case, 99% of my classes and functions are an API to each other. So I look up how the stuff I wrote days, weeks or months ago was supposed to be called or initialized constantly. I read my code more often than I write it.
I like writing CoffeeScript but what matters is -- I love reading it. Before, I liked writing JavaScript -- but I hated reading it.
> As it turns out that isn’t entirely true since coffeescript
> is a class based object oriented language and javascript is
> prototype based. This was actually a mark against
> coffeescript for me since part of my desire to learn
> javascript was to dally in prototype based OOP.
What's in a name? That which we call a class by any other name would smell as sweet.
Call it a prototype if you like -- it's the same thing in code.
I am still a student of computer science and in my university's Java encapsulated worldview they've not discussed the finer points of non class-based OOP. I will do more research on the subject.
An object is a unit of code and data that can be treated as a distinct entity. Classes and prototypes are both way to make objects. With a prototype, you start with an actual object as an example, and make more objects just like it. With a class, you start with the abstract set of properties that describe a type of object, and make more objects from that blueprint.
Think of it as the Platonic ideal of a thing (the class), versus the canonical example of a thing (the prototype).
To get specific: The idea of Bicycle, versus my blue bike with red streamers. Both can be used to make more bikes, in JavaScript.
newBike = new Bicycle
newBike = Object.create(myBlueBike)In books, you typically start from the beginning and read to the end. You consume the book serially and the only breaks you are concerned about are pauses (period, comma, colon, etc.) and page breaks (chapters).
In code, you typically scan. Scanning a book is a painful experience. The sentences never start in the same spot. In code, the heirarchcal structure and text layout helps for scanning and identifying quickly. As someone said previously in this thread, cookbooks are done the same way and for the same reasons.
Also, even without an editor, the cleanliness pays off. And you would indent properly anyway...
Isn't that how we write cooking recipes?
Your comparison with novels I think is a bit skewed. Literature has a whole different set of readability enhancements such as fully justified text, variable-width fonts, as well as margins and padding. Punctuation in English has been evolving for centuries as people settle on the minimum needed to convey the full meaning as unambiguously as possible. But English also has many many more sets of valid (as well as various definitions of valid) constructs than Javascript does and thus may require a more robus set of punctuation.
<html> <body> <ul> <li>First</li> <li>Second</li> <li>Third</li> <li>Fourth</li> </ul> </body>
<script type="text/javascript"> els = document.getElementsByTagName('li'); for(i=0; i < els.length; i++){ els[i].addEventListener('click', function(){alert(i);}, false); } </script> </html>
It drastically reduces the amount of errors in your code, at the expense of a syntax that's a little different.
In HTML I want to focus on document structure, not closing my tags. In CSS I want to focus on style and visual consistency, not nesting. In Javascript I want to focus on application behavior, not semicolons.