Basically, it looks like this. Note how there’s no explicit return statement and how the conditional is an expression.
Another example. Compared to JS prototypes, the syntax is really nice.
Not being a JS ninja, using CS seemed like a great chance to leverage the full power of JS in a UI-heavy project. Having written a few lines of Python and Haskell in the past, the clean, parenthesis-free syntax was enticing and the concept of classes was familiar to a Java developer.
After a few weeks I was in evangelization mode.
Soon, however, everyone’s code started to look a little different. Some used parentheses in function invocations while others didn’t. Classes were used when a simple object literal would have sufficed.
The team found that the CS compiler doesn’t always follow the principle of least astonishment, even if the behavior is documented.
I also noticed that writing new code was accompanied by a feeling of undecidedness, not knowing whether my approach is the idiomatic way to solve a problem. Later I found an article that summarized my feelings about CS, Less typing, bad readability by Manuel Cerón.
As our codebase grew, our makeshift Rhino compiler started to stagger and build times grew to half a minute (with just a few files and a total of < 1000 LOC).
Diversity in the codebase was addressed by employing this style guide with some minor modifications. We started ditching classes in favor of simple object literals and revealing modules. In general we were using CS as it should be used: a simpler way to write JS.
An empty cup
Using CS has been a rocky road but a fun one. It’s fun to write and easy to debug. It gives its wielder a terse, expressive syntax with exceedingly many ways to do things. Unfortunately it’s also easy to shoot yourself and other developers in the feet.