One of the perils of riding blind into the Wild West of Web Programming: Everyone has an opinion on what you should do. What tool you should use, what language you need to flex. It's almost as if they don't want you here...
Up to now I've been using CoffeeScript mainly for my tests - such as they are. I find it highly descriptive and easy to read: a must when reviewing a test suite. This instantly brings up two questions:
I've had equally passionate, stubborn, smart, friendly, and overall lovely devs hit me from either side of the CoffeeScript divide. One friend told me he couldn't read my test suite unless I used CoffeeScript ("what's with the noise dude?") and another ask me if it's possible to see the generated JS so he "could read it with some level of sanity".
I want to reiterate this: both of these guys are well known, super-smart developers as opposed to the thrash/bash crowd on Reddit or HN. These are my friends. Each is suggesting (strongly) I should "choose a side and grab a pistol".
I'm leaning towards that. It doesn't make sense to have both - I want to pick one and move on...
They Keep Pulling Me Back In
I've tried to avoid this decision because, frankly, I think it's overheated and runs the risk of derailing my entire effort here.
And no - these aren't people who are afraid of anything - they are some of the smartest people I know.This is about the time where I'm reminded:
The only way to intelligently ponder this issue is to distill the rhetoric and see if there's something compelling that I can ... drizzle with my experience. Let's do it.
This seems to be the canonical rebuttal against the use of CoffeeScript. I appreciate the author's candor and detailed approach to what he sees as a shortcoming in CoffeeScript. Let's see if I can work this down to something croonable.
The author points out that debugging a problem involves looking at the compiled JS and then stepping back into CoffeeScript to see where you messed up. This is a reasonable point: by using CoffeeScript you've just added syntactic complexity to your application: You could have a CoffeeScript error during CoffeeScript compilation that you need to solve. This, by definition, wouldn't happen if you weren't using CoffeeScript.
You could have a logic error you need to figure out, and now you're climbing through 2 stacks instead of 1. If you're working in the browser this can be an issue, to be sure - you'll have to debug the generated JS, not the CoffeeScript. If you're working in NodeJS (which understands CoffeeScript) - you can get "odd" error messages returned that lack syntactic guides as to where the problem is. Not a very big issue - but it slows down the overall development process.
Consider this code here (a mocha test):
Word is not defined? Of course it's defined! It's VAR dude! Oh right - there is no var is CoffeeScript!
Sure would be nice if the error message said that. And yes - it's a bit of a nit, to be sure. But when you read this output when running a test - wouldn't your first inclination be to check your code under test to see if there's a problem?
This kind of thing slows you down a touch, and it does happen. I don't like going slower.
Readability != Comprehension
But that's reading code - and it's quite different than "readable code" as dumb as that might sound. In the Ruby community, Rubyists will thrash themselves to make a chunk of code aesthetically pleasing as well as immediately "grokkable". This is the goal of the language, and I find it to be amazingly compelling.
This is an excerpt from Ryan Florence's blog (it's beautifully laid out btw):
My takeaway from this is:
Remember, we're talking comprehension here, not syntax excitement. Which sentence sat happier in your brain? If we're going to get literal on comprehending editorial intent: it's a hard and fast rule that you start with a premise and build on it. That's writing 101 (and speaking 101 for that matter): lead with the punchline (or abstract) and then make your case.That's what CoffeeScript favors. But this is a small, silly example anyway.
Throw in the function() keywords a few times with some braces, parens and semi-colon eye-stabbery, then we can talk about "comprehension".
That, to me, is a very very compelling question. I can get over the code noise, and I can figure out the good patterns - so why mess with an interpretor? It seems like extra work for what amounts to syntactic sugar... is it really worth it?
I don't need to add much to this. I've pondered just how much I've written the word "function(..)" over the past years - and a thought occurred to me:
If I had a nickel for every time I wrote "function()", I could almost fill the void that is Avery's head.
(this is a derivation of a joke: "what would you rather have: 1 million dollars or Avery's head full of nickels" - it's a tough question).
Aren't We Trying To Move Forward?
I was talking to a friend the other day and he just flat out said it:
This opinion, while a tad blunt, isn't completely without merit. The language has flaws - flaws that are quite glaring and ones that will bite you by default. Global leaks, scoping issues, inconsistencies in comparisons and equality... this is all well known stuff.
What To Do?
I'm on the fence here, but I feel compelled to make a choice. I'm leaning in the CoffeeScript direction because I enjoy the terser syntax and the Ruby aesthetic, but I also know that there will be times when it slows me down.
I'd love to hear your feedback, but please (as always) provide some reasons I can sink my teeth into and think about. Opinions are welcome too - just try to balance them on things other than links and quotes.I'll be moderating this thread heavily.