6 ms·

While I'm a huge fan of what ES2015 has brought to JavaScript, the "class" keyword was a huge mistake. There are no classes in Javascript, there are only object

by pg_bot 10y ago

While I'm a huge fan of what ES2015 has brought to JavaScript, the "class" keyword was a huge mistake. There are no classes in Javascript, there are only objects. By embracing prototypal inheritance you will write cleaner code with fewer errors.

namelezz 10y ago
Can you give an example of errors introduced by using "class"?
- JSDave 10y ago
  There's a lot of reasons against classes in JS. This list has a lot of articles. https://github.com/joshburgess/not-awesome-es6-classes https://github.com/joshburgess/not-awesome-es6-classes A common point seems to be against the brittleness caused by inheritance (including prototypical) in general. Personally, I find that the tiny amount of performance you give up by using factory and composition patterns is generally worth not having to deal with binding the right context
  - chickenfries 10y ago
    Grand-parent comment asked for an example of an error introduced by using class that would've been avoided with prototype inheritance, and you respond with an "awesome" "curated" list of opinion pieces and conference talks by famous devs and rockstars... This is what's wrong with the JS community and why everything is so hype driven... this list gives the impression that if you want to be a good JS developer you should've even THINK about trying to use classes in your JS because if you do then you don't truly "get" JS. Think for yourself and decide if classes will improve your code in the way you plan to use it. Classes have hugely improved my company's JavaScript, it works well considering our developers understand OOP much better than they do functional programming, which I think is pretty common. We don't rely on inheritance, we reuse by composition (which is just as easy to do with class as it is to do with protypes). Classes are fine! Use them if you want to! Don't use them if your existing code relies heavily on prototypal inheritance, but if you just wanna wrap some methods around some internal state and you like the way the class syntax looks compared to the prototype syntax don't let some think piece on medium try to convince you that classes are bad. EDIT: sorry to go off on a slightly OT rant on your comment... I just got frustrated by the link you posted.
    - JSDave 10y ago
      That list is actually making fun of what you're describing in the JS community. "Not Awesome" is a play on the "Awesome" lists like this [https://github.com/sindresorhus/awesome https://github.com/sindresorhus/awesome] JS classes were extremely hyped up a year ago. Taking a stance against classes was going very hard against the hype. How well your devs understand the code is the only real metric. If you understand OOP better, stick with it!
      - chickenfries 10y ago
        Huh, I must have missed the "classes are great" wave. I only remember the "classes are bad" FUD represented by this list... HN is my main connection to the hype train these days since I quit Twitter. > How well your devs understand the code is the only real metric. If you understand OOP better, stick with it! Agreed.
  - Lazare 10y ago
    That doesn't really answer OPs question though? He's asking about why manipulating prototypes directly is better than doing so via the class keyword sugar, and your response seems to explains why you probably shouldn't do either one.
- pg_bot 10y ago
  Kyle Simpson has a good writeup of the class keyword from his series of books "You don't know Javascript". https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/apA.md https://github.com/getify/You-Dont-Know-JS/blob/master/this%... You can read through the gotchas section and come up with your own conclusions.
- tchaffee 10y ago
  Classes enforce a strict hierarchical relationship which is rarely how the real world works. And you also inherit everything from a parent class whether you need it or not. One alternative to class inheritance possible with javascript is object composition (usually Object.assign()) which does not enforce a hierarchical relationship and you can use only what you want from other objects. More flexible, less brittle. Eric Elliot goes into details with concrete examples in this article. https://medium.com/javascript-scene/master-the-javascript-interview-what-s-the-difference-between-class-prototypal-inheritance-e4cd0a7562e9 https://medium.com/javascript-scene/master-the-javascript-in...
chickenfries 10y ago
> By embracing prototypal inheritance you will write cleaner code with fewer errors. [citation needed] Classes are fine, they're just sugar over prototypal inheritance.
- tantalor 10y ago
  Yes, this why the class keyword is great. Also it fixes inheritance which is not easy to do with prototypes. class A {} > class A {} class B extends A {} > class B extends A {} new B instanceof B > true new B instanceof A > true There is just 1 way to do this with classes, it is very concise, and it is impossible to do wrong, e.g., by forgetting to call the super class constructor. Try doing that with prototypes.
  - MrPatan 10y ago
    That's the thing, with prototypes you don't use inheritance, which is the good option. Now it's easy to do the wrong thing. Thanks ECMA!
    - Lazare 10y ago
      > with prototypes you don't use inheritance That is 100% wrong. Prototypes are inheritance. Quoting from wikipedia: "Prototype-based programming is a style of object-oriented programming in which behaviour reuse (known as inheritance) is performed via a process of reusing existing objects via delegation that serve as prototypes." I have no idea what you were trying to say, but what you wrote is nonsense.
      - cmrdporcupine 10y ago
        Well arguably the definition of inheritance there doesn't meet the poster's idea of inheritance. Prototype 'inheritance' is a kind of delegation and some prototype OO languages make that explicit by using different terminology (Self says 'delegate' and not 'parent' for example). But then arguably in class-based OO languages, classes don't "inherit" either and really just delegate to other classes. (FWIW I wrote a big chunk of the prototype-OO article on WP at one point. Not sure how much of that text still exists)
popopobobobo 10y ago
yeah, let's write js as pure functional language.
- mpfundstein 10y ago
  Check fantasy-land and ramda
draw_down 10y ago
Agreed that `class` was a mistake, but I try to use inheritance (of any kind) as sparingly as possible.
paulddraper 10y ago
> By embracing prototypal inheritance you will write cleaner code with fewer errors. Do you have a concrete example in mind? Code sample A is cleaner and has fewer errors than its class equivalent B?
baron816 10y ago
How about Parasitic Inheritance? http://www.breck-mckye.com/blog/2014/05/why-i-prefer-parasitic-inheritance/ http://www.breck-mckye.com/blog/2014/05/why-i-prefer-parasit... You can get rid of "this" and all it's problems, and the code is even cleaner.
Lazare 10y ago
> the "class" keyword was a huge mistake. There are no classes in Javascript, there are only objects That's true if you define the word "class" to not include JS classes, but in that case, you can use the keyword and still "embrace" prototypal inheritance, since as you say, it's all just objects (even if you use the class keyword). Alternatively if you use a more flexible definition of the word class, then your assertion is not true, because JS does have classes, they just are implemented via prototypes. Either way, I don't see how your comment is correct. Is it all objects, or not? :)
camus2 10y ago
> the "class" keyword was a huge mistake There is not a single fact proving that statement. People want to write Javascript in different ways, Javascript is no less OO that it is FP. I don't see why one camp should be more privileged than the other. > prototypal inheritance you will write cleaner code with fewer errors. JS Classes use "prototype inheritance". compare that : function Foo(){} function Bar(){ Foo.call(this) } Bar.prototype = Object.create(Foo.prototype) with that : class Foo{} class Bar extends Foo{} There is absolutely no debate as to what is more readable, cleaner,easier to parse for IDE, and less error prone. ES6+ is considerably making writing JS easier and safer. There is very little reason today to deal with prototypes directly. And in strict mode, calling Foo or Bar without using new yields an error.
- tchaffee 10y ago
  Encouraging inheritance in the first place is the mistake. Using composition with Object.assign is far less fragile than inheritance. An article with concrete examples: https://medium.com/javascript-scene/master-the-javascript-interview-what-s-the-difference-between-class-prototypal-inheritance-e4cd0a7562e9#.ak2srgk4q https://medium.com/javascript-scene/master-the-javascript-in...
  - camus2 10y ago
    The point the OP was making that the class keyword was a mistake, not that inheritance was a mistake. This is an entirely different topic. Furthermore, Javascript classes make writing mixins AKA composition a breeze, compared to before: http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/ http://justinfagnani.com/2015/12/21/real-mixins-with-javascr... This link is an excellent rebuttal to Eric Elliot article and how he achieve composition through copying by the way. So even if you like composition over inheritance, Javascript classes still allow you to write safer and clearer and cleaner code. Now you can do away with ugly factories and property copying. > Object.assign is far less fragile than inheritance You realize the using Object.assign means copying properties from object to object over and over and increase memory requirements in order to run a script. So my point still stands, there is not a single disadvantage introduced with the class keyword.

by pg_bot 10y ago

namelezz 10y ago

Can you give an example of errors introduced by using "class"?

JSDave 10y ago
There's a lot of reasons against classes in JS. This list has a lot of articles. https://github.com/joshburgess/not-awesome-es6-classes https://github.com/joshburgess/not-awesome-es6-classes A common point seems to be against the brittleness caused by inheritance (including prototypical) in general. Personally, I find that the tiny amount of performance you give up by using factory and composition patterns is generally worth not having to deal with binding the right context
- chickenfries 10y ago
  Grand-parent comment asked for an example of an error introduced by using class that would've been avoided with prototype inheritance, and you respond with an "awesome" "curated" list of opinion pieces and conference talks by famous devs and rockstars... This is what's wrong with the JS community and why everything is so hype driven... this list gives the impression that if you want to be a good JS developer you should've even THINK about trying to use classes in your JS because if you do then you don't truly "get" JS. Think for yourself and decide if classes will improve your code in the way you plan to use it. Classes have hugely improved my company's JavaScript, it works well considering our developers understand OOP much better than they do functional programming, which I think is pretty common. We don't rely on inheritance, we reuse by composition (which is just as easy to do with class as it is to do with protypes). Classes are fine! Use them if you want to! Don't use them if your existing code relies heavily on prototypal inheritance, but if you just wanna wrap some methods around some internal state and you like the way the class syntax looks compared to the prototype syntax don't let some think piece on medium try to convince you that classes are bad. EDIT: sorry to go off on a slightly OT rant on your comment... I just got frustrated by the link you posted.
  - JSDave 10y ago
    That list is actually making fun of what you're describing in the JS community. "Not Awesome" is a play on the "Awesome" lists like this [https://github.com/sindresorhus/awesome https://github.com/sindresorhus/awesome] JS classes were extremely hyped up a year ago. Taking a stance against classes was going very hard against the hype. How well your devs understand the code is the only real metric. If you understand OOP better, stick with it!
    - chickenfries 10y ago
      Huh, I must have missed the "classes are great" wave. I only remember the "classes are bad" FUD represented by this list... HN is my main connection to the hype train these days since I quit Twitter. > How well your devs understand the code is the only real metric. If you understand OOP better, stick with it! Agreed.
- Lazare 10y ago
  That doesn't really answer OPs question though? He's asking about why manipulating prototypes directly is better than doing so via the class keyword sugar, and your response seems to explains why you probably shouldn't do either one.
pg_bot 10y ago
Kyle Simpson has a good writeup of the class keyword from his series of books "You don't know Javascript". https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/apA.md https://github.com/getify/You-Dont-Know-JS/blob/master/this%... You can read through the gotchas section and come up with your own conclusions.
tchaffee 10y ago
Classes enforce a strict hierarchical relationship which is rarely how the real world works. And you also inherit everything from a parent class whether you need it or not. One alternative to class inheritance possible with javascript is object composition (usually Object.assign()) which does not enforce a hierarchical relationship and you can use only what you want from other objects. More flexible, less brittle. Eric Elliot goes into details with concrete examples in this article. https://medium.com/javascript-scene/master-the-javascript-interview-what-s-the-difference-between-class-prototypal-inheritance-e4cd0a7562e9 https://medium.com/javascript-scene/master-the-javascript-in...

chickenfries 10y ago

> By embracing prototypal inheritance you will write cleaner code with fewer errors. [citation needed] Classes are fine, they're just sugar over prototypal inheritance.

tantalor 10y ago
Yes, this why the class keyword is great. Also it fixes inheritance which is not easy to do with prototypes. class A {} > class A {} class B extends A {} > class B extends A {} new B instanceof B > true new B instanceof A > true There is just 1 way to do this with classes, it is very concise, and it is impossible to do wrong, e.g., by forgetting to call the super class constructor. Try doing that with prototypes.
- MrPatan 10y ago
  That's the thing, with prototypes you don't use inheritance, which is the good option. Now it's easy to do the wrong thing. Thanks ECMA!
  - Lazare 10y ago
    > with prototypes you don't use inheritance That is 100% wrong. Prototypes are inheritance. Quoting from wikipedia: "Prototype-based programming is a style of object-oriented programming in which behaviour reuse (known as inheritance) is performed via a process of reusing existing objects via delegation that serve as prototypes." I have no idea what you were trying to say, but what you wrote is nonsense.
    - cmrdporcupine 10y ago
      Well arguably the definition of inheritance there doesn't meet the poster's idea of inheritance. Prototype 'inheritance' is a kind of delegation and some prototype OO languages make that explicit by using different terminology (Self says 'delegate' and not 'parent' for example). But then arguably in class-based OO languages, classes don't "inherit" either and really just delegate to other classes. (FWIW I wrote a big chunk of the prototype-OO article on WP at one point. Not sure how much of that text still exists)

popopobobobo 10y ago

yeah, let's write js as pure functional language.

mpfundstein 10y ago
Check fantasy-land and ramda

draw_down 10y ago

Agreed that `class` was a mistake, but I try to use inheritance (of any kind) as sparingly as possible.

paulddraper 10y ago

> By embracing prototypal inheritance you will write cleaner code with fewer errors. Do you have a concrete example in mind? Code sample A is cleaner and has fewer errors than its class equivalent B?

baron816 10y ago

How about Parasitic Inheritance? http://www.breck-mckye.com/blog/2014/05/why-i-prefer-parasitic-inheritance/ http://www.breck-mckye.com/blog/2014/05/why-i-prefer-parasit... You can get rid of "this" and all it's problems, and the code is even cleaner.

Lazare 10y ago

> the "class" keyword was a huge mistake. There are no classes in Javascript, there are only objects That's true if you define the word "class" to not include JS classes, but in that case, you can use the keyword and still "embrace" prototypal inheritance, since as you say, it's all just objects (even if you use the class keyword). Alternatively if you use a more flexible definition of the word class, then your assertion is not true, because JS does have classes, they just are implemented via prototypes. Either way, I don't see how your comment is correct. Is it all objects, or not? :)

camus2 10y ago

> the "class" keyword was a huge mistake There is not a single fact proving that statement. People want to write Javascript in different ways, Javascript is no less OO that it is FP. I don't see why one camp should be more privileged than the other. > prototypal inheritance you will write cleaner code with fewer errors. JS Classes use "prototype inheritance". compare that : function Foo(){} function Bar(){ Foo.call(this) } Bar.prototype = Object.create(Foo.prototype) with that : class Foo{} class Bar extends Foo{} There is absolutely no debate as to what is more readable, cleaner,easier to parse for IDE, and less error prone. ES6+ is considerably making writing JS easier and safer. There is very little reason today to deal with prototypes directly. And in strict mode, calling Foo or Bar without using new yields an error.

tchaffee 10y ago
Encouraging inheritance in the first place is the mistake. Using composition with Object.assign is far less fragile than inheritance. An article with concrete examples: https://medium.com/javascript-scene/master-the-javascript-interview-what-s-the-difference-between-class-prototypal-inheritance-e4cd0a7562e9#.ak2srgk4q https://medium.com/javascript-scene/master-the-javascript-in...
- camus2 10y ago
  The point the OP was making that the class keyword was a mistake, not that inheritance was a mistake. This is an entirely different topic. Furthermore, Javascript classes make writing mixins AKA composition a breeze, compared to before: http://justinfagnani.com/2015/12/21/real-mixins-with-javascript-classes/ http://justinfagnani.com/2015/12/21/real-mixins-with-javascr... This link is an excellent rebuttal to Eric Elliot article and how he achieve composition through copying by the way. So even if you like composition over inheritance, Javascript classes still allow you to write safer and clearer and cleaner code. Now you can do away with ugly factories and property copying. > Object.assign is far less fragile than inheritance You realize the using Object.assign means copying properties from object to object over and over and increase memory requirements in order to run a script. So my point still stands, there is not a single disadvantage introduced with the class keyword.