4 ms·

It was definitely popular beyond Rubyists - Dropbox was originally a python-based engineering organization, and we picked it up, and a lot of us liked it for a

It was definitely popular beyond Rubyists - Dropbox was originally a python-based engineering organization, and we picked it up, and a lot of us liked it for a few years. I think the main thing to note is that we were supporting IE7+ when we adopted coffeescript. So we couldn't even write standard ES5 - ES3 would have been the lowest common denominator supported. So having classes, optional chaining, array comprehensions, for-in loops that actually looped over items in an array (like ES6 for-of) - all those features were super useful. And you didn't need to worry about function declaration hoisting (or any confusion it could cause) because coffeescript only compiled to function expressions, which got bound to variables. Unfortunately, coffeescript came with some others like implicit returns and tons of optional syntax that we didn't realize was problematic until far too late. And being a python-based org, having a frontend language that looked similar (space-delimited, a lot of similar features e.g. array comprehensions were like list comprehensions, ternaries that looked more readable) seemed like features. But some of these features bit us hard at times, because they didn't work like python - the worst, in my opinion, was that `is not` and `isnt` looked the same but meant very different things in coffeescript. `is not` meaning `=== !` and isnt meant `!==`. But given the alternative was writing prototypical-inheritance by hand, and dealing with various IE7isms directly? It was a sensible tradeoff at the time.

danenania 6y ago
What’s wrong with implicit returns? I’ve always liked those in CoffeeScript and Ruby.
- city41 6y ago
  It can cause surprises. One of the biggest ones is turning a loop into an expression if it’s the last thing a function does. Edit: here is an example https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%20%5B1...3%5D%0A%20%20%20%20console.log%20i https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%2...
  - rraval 6y ago
    Accumulating loop results in an array is bad for perf, but won't necessarily cause logic bugs. My favourite implicit return gotcha comes from the intersection of CoffeeScript and jQuery, where implicitly returning `false` from an event handler implies `preventDefault()` and `stopPropagation()`. This can even cause heisenbugs if your logging throws booleans around.
    - dgoldstein0 6y ago
      Another bad one: returning a jQuery.ajax object, and then consumers of your api may start using it directly. We have that in our codebase still. Not sure if it was intentional or not but it's going to be hard to undo.
  - brlewis 6y ago
    That's specific to Coffeescript. Implicit returns in Scheme don't do that.

danenania 6y ago

What’s wrong with implicit returns? I’ve always liked those in CoffeeScript and Ruby.

city41 6y ago
It can cause surprises. One of the biggest ones is turning a loop into an expression if it’s the last thing a function does. Edit: here is an example https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%20%5B1...3%5D%0A%20%20%20%20console.log%20i https://coffeescript.org/#try:-%3E%20%0A%20%20for%20i%20in%2...
- rraval 6y ago
  Accumulating loop results in an array is bad for perf, but won't necessarily cause logic bugs. My favourite implicit return gotcha comes from the intersection of CoffeeScript and jQuery, where implicitly returning `false` from an event handler implies `preventDefault()` and `stopPropagation()`. This can even cause heisenbugs if your logging throws booleans around.
  - dgoldstein0 6y ago
    Another bad one: returning a jQuery.ajax object, and then consumers of your api may start using it directly. We have that in our codebase still. Not sure if it was intentional or not but it's going to be hard to undo.
- brlewis 6y ago
  That's specific to Coffeescript. Implicit returns in Scheme don't do that.