[d_k_f]

In addition to this: ruby-like classes and "sane"/expected handling of this using fat arrow functions. I've worked with a few developers at the time that considered themselves pure backend/rails developers and didn't (bother to) grok the details around the way this worked in JS.

I distinctly remember lots of var that = this; in JS code back then, which wasn't required anymore when using CoffeScript.

[mikepurvis]

Class sanity was the major reason I chose it for a project in the early 2010s. I was interacting with the classes in OpenLayers and being able to do so without all those footguns was very welcome.

[PH95VuimJjqBqy]

javascript was never designed to be used like a classic OOP language, that's why jquery won, it was functional which meant it didn't fight you the way the other libraries did.

javascript is first and foremost functional no matter how hard MS and others have tried to hammer it into a more typical OOP language.

[Dylan16807]

I'm not sure what you mean. You can put functions into objects, you have "this" when you call the functions, you even have prototypes. It seems to me like the language is designed to let you do OOP just fine, and the only thing that was awkward was organizing the code where you define all those functions and the constructor. So they added a sugar keyword for it.

[PH95VuimJjqBqy]

right, it's awkward, so don't do that, be functional instead.

jquery vs mootools/scriptaculous/etc.

jquery won for a reason, it's just flat out a better experience in terms of code specifically because it uses a functional approach in its api rather than an OOP approach.

[Dylan16807]

> right, it's awkward, so don't do that, be functional instead.

I feel like you're just saying that because you like functional code. I'm sure that when they've added syntax to make certain functional things easier to type, you didn't respond "it's awkward, so don't do that, write it in an entirely different way instead".

Regardless of what is "better", which tends to differ based on situation, there was no need for the awkwardness. Classes weren't bad to use, it was just that declaring them had some pointless busywork.

[PH95VuimJjqBqy]

implicit in my responses is an assumption that you've worked extensively with jquery so you understand the syntax and how it's functional.

If you don't the only response I can have is to go learn it.

This isn't about functional being better, it's about functional being more fluid to use in javascript.

[jeroenhd]

I would argue that fat arrow functions really are nothing more than synctactic sugar. I don't know of any place where (x,y) => {} couldn't be replaced by function(x,y){}. I prefer arrow functions myself, but it's a very minor additions.

Fixing _this_ is a good point, though.

[d_k_f]

When you didn't know how this worked, CoffeScript's fat arrow functions became a life saver when attaching callbacks from inside some object you were writing that probably had an init() method to set up the handlers:

  // Doesn't work, <this> is <window>.
  document.body.addEventListener("click", function(event) { this.handleClick(event) })

vs.

  document.body.addEventListener "click", (event) => @handleClick(event)

You only needed a .bind(this) in the plain JS version, but it felt like surprisingly few people knew this back then.

Interestingly enough, the current version of CoffeeScript compiles this code into a ES6 arrow function itself, but I think back then they used bind() in the transpiled JS.