Live data from Hacker News

A Case Against Using CoffeeScript

ryanflorence.com

121–130 of 142 posts

Re: A Case Against Using CoffeeScript

#121

There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…

I don't understand what the big deal is. If you don't want to use coffeescript then don't use coffeescript.

Re: A Case Against Using CoffeeScript

#122

There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…

Heh, you're framing the question in a way that is more likely to elicit positive CoffeeScript comments, but I'm happy to oblige.

In order to adopt any new language, you obviously need to eventually believe its benefits are greater than its hurdles.

CS had a few hurdles for me early in the process. I had to install it, and that was simple. Then I had to learn it, which was fairly easy. It helped me that I had a fairly strong foundation in Python, Ruby, and JS, and the subset of CS that I initially learned is largely a blend of those languages. The language is small and well-documented. (Hopefully we keep it small--there's a bit of creeping featuritis in the community.)

Debugging is the only ongoing hurdle. It's never been a big issue for me. Obviously, I try to write the code correctly in the first place, and CS's nice syntax helps me focus on writing correct logic by removing the need to deal with JS boilerplate code. When I still manage to write incorrect code, I use all the debugging tools that I would use to debug JS. Someday my ability to write large JS programs may atrophy, but I'll never forget how to read it or make simple modifications in the debugger.

Even if the hurdles of CS were relatively minor, it would be pointless to use CS if it gave me no benefits. For me the benefits of CS are its writability and readability. It's that simple.

I'm already sold on CS, but I could still suggest ways to minimize the hurdles. First, keep the language small and simple. Second, no matter how good the current docs are (and they are pretty good), continue to refine them. Finally, do everything possible on the CS side to facilitate debugging, which mostly comes down to line number support.

Re: A Case Against Using CoffeeScript

#123

There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…

Are there examples of large(ish) projects or production websites using primarily CoffeeScript?

It seems like CS has a fanbase among purists who enjoy the syntactic elegance. But in more pragmatic environments the extra pain in the develop-debug lifecycle would seem to be a showstopper. I just wonder how many developers end up voting with their feet when confronted with that choice in the real world.

P.S. Another argument against that wasn't mentioned: CoffeeScript represents an additional barrier to entry for opensource projects. Shipping compiled JS code is not unlike shipping a compiled binary... and if you want people to participate and contribute, requiring CS knowledge is an extra hurdle that most JS devs will shy away from.

Re: A Case Against Using CoffeeScript

#124

There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…

With JavaScript ordinary developers hit a wall at some point and can't make further progress. Like Java has shown, how good the language is seems secondary to how good the implementation, the runtime, is. JavaScript runtimes have kept on improving and with the V8/Node.JS combination have started taking over the server-side code. With careful engineering, developers can get even further with just JavaScript the langua…

With JavaScript ordinary developers hit a wall at some point and can't make further progress.

Can you elaborate a bit on this? I still feel like I'm new to JS and am interested in what lurks ahead.

Re: A Case Against Using CoffeeScript

#125

There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…

Heh, you're framing the question in a way that is more likely to elicit positive CoffeeScript comments, but I'm happy to oblige. In order to adopt any new language, you obviously need to eventually believe its benefits are greater than its hurdles. CS had a few hurdles for me early in the process. I had to install it, and that was simple. Then I had to learn it, which was fairly easy. It helped me that I had a fairly…

* Keep the language small and simple.

* Continue to refine the documentation.

* Work on source map support (when it lands in browsers).

I think you've basically just outlined the current roadmap ;)

Re: A Case Against Using CoffeeScript

#126
post #123

There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…

Are there examples of large(ish) projects or production websites using primarily CoffeeScript? It seems like CS has a fanbase among purists who enjoy the syntactic elegance. But in more pragmatic environments the extra pain in the develop-debug lifecycle would seem to be a showstopper. I just wonder how many developers end up voting with their feet when confronted with that choice in the real world. P.S. Another argu…

I agree wholeheartedly, hence the initial question...

Here's a few examples of production sites/apps off the top of my head:

http://getcloudapp.com/

https://posterous.com/

https://widescript.com/

http://basecamphq.com/mobile/

http://itunes.apple.com/us/app/ars-technica/id393859050

Re: A Case Against Using CoffeeScript

#127

Earlier quoted context omitted.

One wouldn't know that intuitively, because what you wrote: longRunning () -> "Yippee!" () -> "Oh noes" ... is not valid CoffeeScript. I'm not sure where you got that from. Ideally, you'd write it: longRunning onSuccess, onError Or, if you really wanted to use two inline functions instead of local variables: longRunning (-> "Yippee!"), (-> "Oh noes")

Thanks. A more realistic example would, I suppose, look like this: longRunning (-> ### bunch of stuff happening for success ### ), (-> ### bunch of stuff happening for failures ### )

Yes, that'll work fine, as will this, if you prefer:

    longRunning ->
      # bunch of stuff happening for success
    , ->
      # bunch of stuff happening for failures

Re: A Case Against Using CoffeeScript

#128

There has always been a strong "case against using CoffeeScript", from day one. Like any other new language, it's a new, strange thing to learn, there's new tools and a new compiler, and your team doesn't already know it. In addition, CoffeeScript has it's own distinct burden to bear: the entire point is to compile (in as straightforward a fashion as we can manage) into JavaScript. That you're debugging JavaScript wh…

With JavaScript ordinary developers hit a wall at some point and can't make further progress. Like Java has shown, how good the language is seems secondary to how good the implementation, the runtime, is. JavaScript runtimes have kept on improving and with the V8/Node.JS combination have started taking over the server-side code. With careful engineering, developers can get even further with just JavaScript the langua…

Just to clarify one thing, it's very unlikely that you'll take a 50% performance hit when moving from JS to CoffeeScript. That may be true for Dart as well--I don't know.

Also, since CoffeeScript transcompiles to JS, it will generally reap the benefits of future improvements to JS runtimes, packaging tools, etc.

Re: A Case Against Using CoffeeScript

#129
post #48

I think this article is a mix of fair criticisms but at points lapses into a lot of hand waving. At points it devolves into "This is confusing/non-intuitive if you don't know CS" and "This is not the way I like to do things". I find the proposition that porting a library (no matter the size) gives you "as much experience as anyone" pretty dubious. It's clear the author has some experience with CS, and I wouldn't disc…

"At points it devolves into 'This is confusing/non-intuitive if you don't know CS' and 'This is not the way I like to do things'."

Sure. Most of the arguments for CoffeeScript itself pretty much boil down to "JS is confusing/non-intuitive if you don't know JS" and "This is not the way I like to do things."

Re: A Case Against Using CoffeeScript

#130
post #2

The increase in debugging complexity is a fair point, and it does add an extra step in between finding a problem and fixing it. However, in practice, I'm not sure I've ever had this be a major problem; I've had more problems related to bad error messages from the Coffeescript compiler (generally due to significant-whitespace errors) than I have had in trying to associate Javascript to its source Coffeescript. The res…

> Which is exactly what the fat arrow does in Coffeescript. Except when there's a regression in the compiler, and then it doesn't. https://github.com/jashkenas/coffee-script/issues/1842 It's all good though, because "Pull requests are always welcome." :P

That regression is now fixed here: https://github.com/jashkenas/coffee-script/issues/1842#commi...
Post reply on HN