But CoffeeScript doesn't feel this way to me, which makes me want to stay far away. Yet so many smart people are building cool things with it, which makes me wonder if I just need to suck it up and get familiar with this new syntax.
But CoffeeScript doesn't feel this way to me, which makes me want to stay far away. Yet so many smart people are building cool things with it, which makes me wonder if I just need to suck it up and get familiar with this new syntax.
Coffeescript is has a much trickier syntax than javascript, and if you use it all the time, then the brevity and reduced line noise is a slight win, but you never lose the downsides of the complex syntax.
If you're wondering what's wrong with coffeescript, it basically boils down to the fact that the syntax is chock full of unexpected exceptions. I notice that I and everyone I know sometimes get's surprised by what a piece of syntax actually compiles to (not a good sign).
Some examples:
f
a: 1
b: 2
compiles to f({ a: 1, b: 2 });
but f
o
fails to compile (so whether you can break an argument onto the next line depends on whether it's an object literal)Comma's to delimit multi-line arguments are usually redundant, but not on the first line, so...
f 1,
2
3
compiles to f(1, 2, 3)
but f 1
2
3
doesn't compile at all.Curly braces aren't entirely optional, so
o = [ {
a: 1
b
} ]
compiles to o = [ { a: 1, b: b } ]
but o = [
a: 1
b
]
compiles to o = [ {a:1}, b]
Note that this is particularly tricky if you have functions with complexly nested arguments, which is what the original artical is proposing to use for React. In JS that would be messy but unsurprising, but in coffeescript you will run into the occasional miscompilation, especially since it's indent sensitive but very flexible with those indents.For example you may start out with:
a
href: uri
span
className: "x"
"content"
...then decide to remove the class, and end up with... a
href: uri
span
"content"
But the second example actually nests the content inside the <a>, not the <span> (and it'll crash at runtime since span is passed rather than called).You can even have code that compiles & runs and just returns the wrong value:
div
id: "foo"
span null
"content"
vs. div
id: "foo"
span null,
"content"
Both result in valid JS that would run and display a valid DOM using React, but that comma changes the generated DOM. No warnings, no errors.All in all, I'd stay away from coffeescript if I didn't already have a large codebase to maintain. There are a bunch of other, better, compile-to-JS alternatives to make JS syntax less onerous - so you can get coffeescript's advantages without the nasty pitfalls.
eS6 will have fat arrows, but comparing CS today to JS today, I find the -> and => constructs are more than just an abbreviation, they make it radically easier to write AND READ code that makes heavy use of functions.
YMMV, of course!
There are better ways to learn new languages but cs is familiar enough to js that once you start coding you'll see it comes more naturally than you think.