5 ms·

Hopefully this will clear the whole "class" thing in javascript up with some people. Every time I mention using classes in Javascript I get the obligatory respo

Hopefully this will clear the whole "class" thing in javascript up with some people. Every time I mention using classes in Javascript I get the obligatory response, "That's stupid, they are not actual classes, just syntactic sugar. I'm not using that!" face palm Yes, I know...but look at how much nicer that is to type than his first example... Pretty good, straight forward write up though!

jonahx 11y ago
Douglas Crockford says that classes were the single worst mistake in es6. So it's not really a face palm: https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=5m https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=5m
- jtuchsen 11y ago
  Is his entire complaint that the syntax looks too much like Java? The fact is, people are already using prototypes to share common methods across objects, and classes are really nice short syntactic sugar for doing that. His comment on classes there is too flippant to even know the meaning of his complaint. Beyond that I'd argue that classes give you more guarantees about how an object will behave at the expense of flexibility, although they give you escape hatches if you like. The reduced flexibility is really nice because you can define safe subsets of the language in which tools that analyze and refactor code are possible, even across files if you're using the module system. Moving the language in a direction where consistent universal tooling is possible to write is something that I love about classes, and is often overlooked in discussions about it. I don't care that classes are just a simplified subset feature of what's possible using prototypes, it covers the common case well enough and makes it possible to write really nice code completetion and refactoring tools that don't randomly break. That's worth all the extra magic in my opinion.
  - roebk 11y ago
    Personally I find the OLOO style much simpler, cleaner system. I'd be interested to know why you'd choose class over Object.create()
    - jtuchsen 11y ago
      People do weird metaprogramming things with the existing constructs. In a lot of cases it's because people prefer to keep things DRY, but it hurts when you're trying to grep through a large codebase to find that one method you need. A contrived example: function Animal() {} function Cat() {} Cat.prototype = Object.create(Animal.prototype); (function(fields) { fields.forEach(function(field) { Cat.prototype[field] = function() { // Some nonsense }; }); })(['what', 'the', 'hell']); It's impossible to statically infer what methods are being declared in ES5 code in general. You can pick up on some common assignment patterns, but not all the weird stuff people do. Just check out the top 10 NPM modules and I guarantee you'll find some odd assignment patterns. I can remember that the "colors" module did meta stuff when I last checked. You can't just easily run the code to find out what the module is exporting either, because of potential side effects from IO. You can wrap Node's core IO modules, but that solution is specific to Node, and still won't cover every possible case. In short, it's a huge pain to write tools to pull information out of Javascript code in general, and that hurts the tooling ecosystem around Javascript. With the class pattern you at least have some staticly inferable information you're sure you can pull out of the class, and weird stuff is discouraged. I know in some ways that this is a weak argument, because of the new square bracket assignment, and the fact that anyone can muck with the prototype of the class after it's created. Even still, for the simple OLOO case it does encourage people to write code that has method names that can easily be staticly inferred, and that's a good thing for JS tooling possibilities. I really just want omnicompletion that doesn't randomly break on me! The OLOO pattern is one that's incredibly common in JS
- mhd 11y ago
  There's no rest for the Java programmer, now even JS coders join the SmallTalk/Lisp elite… Is Crockford's dislike still based on this: http://www.crockford.com/javascript/inheritance.html http://www.crockford.com/javascript/inheritance.html ? Because I don't quite buy into that line of thinking. I'm really looking forward to webassembly…
  - voyou 11y ago
    I think Crockford is wrong in that linked article. What he presents as unique features of prototype-based OO seem to really be features of highly dynamic OO. All of the things he implements in that article could be implemented just as easily (indeed, in more-or-less the same way) in Python or Smalltalk, couldn't they?
- wnevets 11y ago
  I gotta agree with him, the class sugar is just the continuation of the 'new' mistake.
- noobermin 11y ago
  That was actually a great talk, I'm happy I'm not the only one in the world that doesn't use new...and the dec64 idea sounds freaking awesome
sago 11y ago
It's a Faustian bargain. It blesses Javascript with a wider audience, less initial balking by new JS programmers, and a few characters for established JS programmers. But it does so by deliberately misleading programmers by naming the syntax to be the same as the thing they think they want, but JS doesn't contain. That seems like a dick move that condemns a whole slew of new developers to permanent misunderstanding of what they're writing, and a fundamental lack of clarity on prototypical inheritance. I will use it. Because syntactic sugar in this case does save some work. But I'm very conscious the code has swapped superficial clarity for deep lies. I suspect Stack Overflow will overflow with even more 'javascript OO is broken' questions and the MDN article won't make more than a dent on clearing up that (deliberate) confusion. I agree with Crockford on this.
- frik 11y ago
  I agree with Crockford too. It's Microsoft, Eich & co that pushed the class syntax based on ideas that originated in TypeScript. I am very grateful to Crockford for the "Good Parts" book and JS5 - I like that lean approach.
- TazeTSchnitzel 11y ago
  The flexibility of prototypical inheritance is one of JavaScript's greatest assets. JavaScript: The Good Parts includes several different approaches to OOP which prototypes make possible. `class` just picks one and pretends the rest never existed.
  - frik 11y ago
    Exactly! Sadly many misunderstand JavaScript and don't even know or misunderstand prototype-based inheritance: https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming Lua is another well know language that has prototype-based inheritance.
  - chc 11y ago
    I don't see what's wrong with that. Converging on one way of doing things is part of the purpose of a standard. We still have the option of implementing a different method if we prefer, just as much as we ever did.
fallat 11y ago
It is important they understand what is really happening though, or else they're in for a few surprises.

jonahx 11y ago

Douglas Crockford says that classes were the single worst mistake in es6. So it's not really a face palm: https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=5m https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=5m

jtuchsen 11y ago
Is his entire complaint that the syntax looks too much like Java? The fact is, people are already using prototypes to share common methods across objects, and classes are really nice short syntactic sugar for doing that. His comment on classes there is too flippant to even know the meaning of his complaint. Beyond that I'd argue that classes give you more guarantees about how an object will behave at the expense of flexibility, although they give you escape hatches if you like. The reduced flexibility is really nice because you can define safe subsets of the language in which tools that analyze and refactor code are possible, even across files if you're using the module system. Moving the language in a direction where consistent universal tooling is possible to write is something that I love about classes, and is often overlooked in discussions about it. I don't care that classes are just a simplified subset feature of what's possible using prototypes, it covers the common case well enough and makes it possible to write really nice code completetion and refactoring tools that don't randomly break. That's worth all the extra magic in my opinion.
- roebk 11y ago
  Personally I find the OLOO style much simpler, cleaner system. I'd be interested to know why you'd choose class over Object.create()
  - jtuchsen 11y ago
    People do weird metaprogramming things with the existing constructs. In a lot of cases it's because people prefer to keep things DRY, but it hurts when you're trying to grep through a large codebase to find that one method you need. A contrived example: function Animal() {} function Cat() {} Cat.prototype = Object.create(Animal.prototype); (function(fields) { fields.forEach(function(field) { Cat.prototype[field] = function() { // Some nonsense }; }); })(['what', 'the', 'hell']); It's impossible to statically infer what methods are being declared in ES5 code in general. You can pick up on some common assignment patterns, but not all the weird stuff people do. Just check out the top 10 NPM modules and I guarantee you'll find some odd assignment patterns. I can remember that the "colors" module did meta stuff when I last checked. You can't just easily run the code to find out what the module is exporting either, because of potential side effects from IO. You can wrap Node's core IO modules, but that solution is specific to Node, and still won't cover every possible case. In short, it's a huge pain to write tools to pull information out of Javascript code in general, and that hurts the tooling ecosystem around Javascript. With the class pattern you at least have some staticly inferable information you're sure you can pull out of the class, and weird stuff is discouraged. I know in some ways that this is a weak argument, because of the new square bracket assignment, and the fact that anyone can muck with the prototype of the class after it's created. Even still, for the simple OLOO case it does encourage people to write code that has method names that can easily be staticly inferred, and that's a good thing for JS tooling possibilities. I really just want omnicompletion that doesn't randomly break on me! The OLOO pattern is one that's incredibly common in JS
mhd 11y ago
There's no rest for the Java programmer, now even JS coders join the SmallTalk/Lisp elite… Is Crockford's dislike still based on this: http://www.crockford.com/javascript/inheritance.html http://www.crockford.com/javascript/inheritance.html ? Because I don't quite buy into that line of thinking. I'm really looking forward to webassembly…
- voyou 11y ago
  I think Crockford is wrong in that linked article. What he presents as unique features of prototype-based OO seem to really be features of highly dynamic OO. All of the things he implements in that article could be implemented just as easily (indeed, in more-or-less the same way) in Python or Smalltalk, couldn't they?
wnevets 11y ago
I gotta agree with him, the class sugar is just the continuation of the 'new' mistake.
noobermin 11y ago
That was actually a great talk, I'm happy I'm not the only one in the world that doesn't use new...and the dec64 idea sounds freaking awesome

sago 11y ago

It's a Faustian bargain. It blesses Javascript with a wider audience, less initial balking by new JS programmers, and a few characters for established JS programmers. But it does so by deliberately misleading programmers by naming the syntax to be the same as the thing they think they want, but JS doesn't contain. That seems like a dick move that condemns a whole slew of new developers to permanent misunderstanding of what they're writing, and a fundamental lack of clarity on prototypical inheritance. I will use it. Because syntactic sugar in this case does save some work. But I'm very conscious the code has swapped superficial clarity for deep lies. I suspect Stack Overflow will overflow with even more 'javascript OO is broken' questions and the MDN article won't make more than a dent on clearing up that (deliberate) confusion. I agree with Crockford on this.

frik 11y ago
I agree with Crockford too. It's Microsoft, Eich & co that pushed the class syntax based on ideas that originated in TypeScript. I am very grateful to Crockford for the "Good Parts" book and JS5 - I like that lean approach.
TazeTSchnitzel 11y ago
The flexibility of prototypical inheritance is one of JavaScript's greatest assets. JavaScript: The Good Parts includes several different approaches to OOP which prototypes make possible. `class` just picks one and pretends the rest never existed.
- frik 11y ago
  Exactly! Sadly many misunderstand JavaScript and don't even know or misunderstand prototype-based inheritance: https://en.wikipedia.org/wiki/Prototype-based_programming https://en.wikipedia.org/wiki/Prototype-based_programming Lua is another well know language that has prototype-based inheritance.
- chc 11y ago
  I don't see what's wrong with that. Converging on one way of doing things is part of the purpose of a standard. We still have the option of implementing a different method if we prefer, just as much as we ever did.

fallat 11y ago

It is important they understand what is really happening though, or else they're in for a few surprises.