5 ms·

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 consi

by d_k_f 3y ago

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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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 3y ago
        > 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 3y ago
        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.
        Dylan16807 3y ago
        I've used it a moderate amount. But I'm not here to argue about how fluid functional code is, I'm here say that OOP works fine, and making slight changes to improve that experience is good. We don't need to actively discourage OOP by making it awkward. Especially when you're not dealing with the DOM, sometimes objects work quite well. The original awkwardness does not show that javascript "was never designed to be used like a classic OOP language". Nor is it why jquery worked well. And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP".
        PH95VuimJjqBqy 3y ago
        > And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP". this is disingenuous and I'm ending it here. MS spent years trying, and initially failing, to get javascript to work in a more traditionally OOP way. describing that as slight is something else.
jeroenhd 3y ago
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 3y ago
  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.

by d_k_f 3y ago

mikepurvis 3y ago

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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      > 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 3y ago
        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.
        Dylan16807 3y ago
        I've used it a moderate amount. But I'm not here to argue about how fluid functional code is, I'm here say that OOP works fine, and making slight changes to improve that experience is good. We don't need to actively discourage OOP by making it awkward. Especially when you're not dealing with the DOM, sometimes objects work quite well. The original awkwardness does not show that javascript "was never designed to be used like a classic OOP language". Nor is it why jquery worked well. And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP".
        PH95VuimJjqBqy 3y ago
        > And adding these slight changes is not trying to "hammer" javascript into being "more typical OOP". this is disingenuous and I'm ending it here. MS spent years trying, and initially failing, to get javascript to work in a more traditionally OOP way. describing that as slight is something else.

jeroenhd 3y ago

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 3y ago
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.