3 ms·

I think some JavaScript developers feel a sort of stockholm-syndrome attachment to the features of JavaScript that make it unique. We've been hearing for so ma

I think some JavaScript developers feel a sort of stockholm-syndrome attachment to the features of JavaScript that make it unique. We've been hearing for so many years that our bread and butter language was terrible, so we told ourselves that other people just hadn't spent the time to take advantage of the less commonly understood features of JS (not unique, just lest common among popular industry languages like python, java, etc). This leads to people claiming that prototypal inheritance always better than classical inheritance (everyone else who uses classes are just misguided), or that JavaScript is "functional" just because it has first class functions. I used to feel this way about classes too. Now that I've started using them at work I feel like there is a great desire to justify the amount of time that has been spent hacking on prototypal inheritance to behave like classes.

Raphmedia 10y ago
When the language featured prototypal inheritance as its main workhorse, it was stupid to try and hack classes together simply because you couldn't wrap your head around prototypal inheritance. That's like if I started to use python and instead of using classes I hacked together a prototypal inheritance system because classes were too outlandish for me. Now that the newest versions of ES brings classes out of the box the point is moot. Use the one you are comfortable with or the one your team agreed with.
- chickenfries 10y ago
  I agree, in the past, it would've been better for everyone to adopt prototypal inheritance instead of the dozens of half-baked class implementations we have now, but the fact that people tried to hack classes into JS shows that prototypal inheritance was the wrong design choice in the first place. JavaScript developers (in the general, not just the ones on HN) wanted classes.
  - Raphmedia 10y ago
    I think it really depends in what order you learn things. If you start your career with web technologies and your first programming language is JS, you have no issues with prototypal inheritance. The problem is when have developers that are used to classical inheritance and expect them to do a bit of JS on the side. Of course they wouldn't want to learn a new mindset simply to "add some blink on the website".
    - voyou 10y ago
      TBH, I think the main difficulty is caused by people claiming there's some huge difference between prototype based and class based OO. There isn't, really (at least, not if you're comparing JavaScript and other widely used dynamic OO languages; prototype-based languages which emphasise copying, rather than delegation, are a bit more different). In both cases, you can share behaviour between objects by putting that behaviour in another object and attaching it in a special way to the objects that should have similar behaviour - in JavaScript it's called __proto__, in Python it's called __class__, etc. Python (and Ruby, Smalltalk, and others) introduce an additional "meta" level of shared behaviour between all these class objects, whereas JavaScript (and Self) don't, but that's a comparatively technical implementation detail. Most languages other than JavaScript are include slightly more language-level support for one particular pattern of using this shared behaviour, which gives users of these languages a strong hint as to how to use these capabilities. The addition of a class keyword to JavaScript is good because it emphasises what JavaScript shares with other dynamic OO languages.
      - chickenfries 10y ago
        Exactly. I don't get what secret superpowers I'm supposed to be gaining by using prototype OO over classes. One of them is just more familiar to the vast majority of programmers.
    - Lazare 10y ago
      > The problem is when have developers that are used to classical inheritance That's a very, very broad category, and some implementations are very close to JS. Python is normally considered to have "classical inheritance", but as a practical matter for day-to-day programming Python inheritance works very similarly to how JS prototypes work (eg, having an inheritance chain and checking methods as you go up the chain until you find something that implements what you're looking for). I find that when people try to emphasise how different JS is from other languages, what they generally mean is how different it is from Java. :)

Raphmedia 10y ago

When the language featured prototypal inheritance as its main workhorse, it was stupid to try and hack classes together simply because you couldn't wrap your head around prototypal inheritance. That's like if I started to use python and instead of using classes I hacked together a prototypal inheritance system because classes were too outlandish for me. Now that the newest versions of ES brings classes out of the box the point is moot. Use the one you are comfortable with or the one your team agreed with.

chickenfries 10y ago
I agree, in the past, it would've been better for everyone to adopt prototypal inheritance instead of the dozens of half-baked class implementations we have now, but the fact that people tried to hack classes into JS shows that prototypal inheritance was the wrong design choice in the first place. JavaScript developers (in the general, not just the ones on HN) wanted classes.
- Raphmedia 10y ago
  I think it really depends in what order you learn things. If you start your career with web technologies and your first programming language is JS, you have no issues with prototypal inheritance. The problem is when have developers that are used to classical inheritance and expect them to do a bit of JS on the side. Of course they wouldn't want to learn a new mindset simply to "add some blink on the website".
  - voyou 10y ago
    TBH, I think the main difficulty is caused by people claiming there's some huge difference between prototype based and class based OO. There isn't, really (at least, not if you're comparing JavaScript and other widely used dynamic OO languages; prototype-based languages which emphasise copying, rather than delegation, are a bit more different). In both cases, you can share behaviour between objects by putting that behaviour in another object and attaching it in a special way to the objects that should have similar behaviour - in JavaScript it's called __proto__, in Python it's called __class__, etc. Python (and Ruby, Smalltalk, and others) introduce an additional "meta" level of shared behaviour between all these class objects, whereas JavaScript (and Self) don't, but that's a comparatively technical implementation detail. Most languages other than JavaScript are include slightly more language-level support for one particular pattern of using this shared behaviour, which gives users of these languages a strong hint as to how to use these capabilities. The addition of a class keyword to JavaScript is good because it emphasises what JavaScript shares with other dynamic OO languages.
    - chickenfries 10y ago
      Exactly. I don't get what secret superpowers I'm supposed to be gaining by using prototype OO over classes. One of them is just more familiar to the vast majority of programmers.
  - Lazare 10y ago
    > The problem is when have developers that are used to classical inheritance That's a very, very broad category, and some implementations are very close to JS. Python is normally considered to have "classical inheritance", but as a practical matter for day-to-day programming Python inheritance works very similarly to how JS prototypes work (eg, having an inheritance chain and checking methods as you go up the chain until you find something that implements what you're looking for). I find that when people try to emphasise how different JS is from other languages, what they generally mean is how different it is from Java. :)