6 ms·

> but the only reason for doing so was "my code doesn't look like it does in other languages"... As much as I beat the FP drum these days at work, I find the c

> but the only reason for doing so was "my code doesn't look like it does in other languages"... As much as I beat the FP drum these days at work, I find the class syntax a much nicer way of organizing solutions to certain, pardon the pun, classes of problems. Whether or not you find this to be semantic diabetes is a matter of taste, I suppose. I'm curious what, specifically, you find to be the major issue that makes you say they should have been left out.

nojvek 8y ago
ES6 classes were such a relief compared to the prototype bloat you had to right. I love syntactic sugar that makes my life easier. ES6+ flavors of JS & Typescript really made me take web programming seriously again.
- noir_lord 8y ago
  Agreed, classes with typescript and Vue make sense to me in a SFC approach. Something about components just fits the class model well.
- wow-bot 8y ago
  also agree, would not go back. TypeScript is savage
- elyobo 8y ago
  I loved the classes at first, but as I've got more in to it I've found that classes and prototypes are redundant. Closures let me maintain all of the state that I need without the extra boilerplate.
- workinthehead 8y ago
  Or, you know, you could actually learn the language you use. Prototypes are not nearly as bloated as classes, and you usually don't even need them. OO is not the one true paradigm of coding.
shados 8y ago
There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better, in term of code organization, isolation, and extensibility. For the 6 times a year where I need an actual class (it does happen!), I can write the prototype code. The main issue with adding classes is that they're very, very complex if you want to make them useful. The initial version was pretty harmless, but it was also almost pointless. Now they need to back fill all of the missing features (eg: private fields), which brings in an enormous amount of complexity. Most of the time, if I need private fields, I can just use symbols (not quite private, but close), or I can do function() { let private = 123; return { // use private in functions here } } It adds (there ARE things classes are better add) very little compared to the insane amount of work that has to be put in the language to get it all working. Decorators are in a similar boat, where many decorator usages can be expressed just as easily with a higher order function, so adding the extra syntax is just bloat. The cost isn't worth the reward. The biggest thing classes give us that is very difficult to replace in vanilla javascript is a semantic construct that is easy to statically analyzed. In the typed flavors (Flow, TypeScript), I can analyze the interface of plain objects, but not in vanilla JS. Part of why React using ES6 classes can be useful. Thats a great benefit, but Im not sure it's worth the trouble.
- styfle 8y ago
  > There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better That's a really good point. I was about to disagree with you but then I created a thought experiment. Thought Experiment: I wonder what the JS landscape would look like if ES6 Modules were introduced as part of ES5 about 8 years ago? I could definitely see how that would make classes fare less appealing if we already had a great module system (sure CJS existed but browser didn't support it). Looking at the timeline of when these features were implemented in all major browsers: * ES6 Class[0]: implemented 2.5 years ago * ES6 Modules[1]: implemented 1 month ago [0]: https://caniuse.com/#feat=es6-class https://caniuse.com/#feat=es6-class [1]: https://caniuse.com/#feat=es6-module https://caniuse.com/#feat=es6-module
  - shados 8y ago

nojvek 8y ago

ES6 classes were such a relief compared to the prototype bloat you had to right. I love syntactic sugar that makes my life easier. ES6+ flavors of JS & Typescript really made me take web programming seriously again.

noir_lord 8y ago
Agreed, classes with typescript and Vue make sense to me in a SFC approach. Something about components just fits the class model well.
wow-bot 8y ago
also agree, would not go back. TypeScript is savage
elyobo 8y ago
I loved the classes at first, but as I've got more in to it I've found that classes and prototypes are redundant. Closures let me maintain all of the state that I need without the extra boilerplate.
workinthehead 8y ago
Or, you know, you could actually learn the language you use. Prototypes are not nearly as bloated as classes, and you usually don't even need them. OO is not the one true paradigm of coding.

shados 8y ago

There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better, in term of code organization, isolation, and extensibility. For the 6 times a year where I need an actual class (it does happen!), I can write the prototype code. The main issue with adding classes is that they're very, very complex if you want to make them useful. The initial version was pretty harmless, but it was also almost pointless. Now they need to back fill all of the missing features (eg: private fields), which brings in an enormous amount of complexity. Most of the time, if I need private fields, I can just use symbols (not quite private, but close), or I can do function() { let private = 123; return { // use private in functions here } } It adds (there ARE things classes are better add) very little compared to the insane amount of work that has to be put in the language to get it all working. Decorators are in a similar boat, where many decorator usages can be expressed just as easily with a higher order function, so adding the extra syntax is just bloat. The cost isn't worth the reward. The biggest thing classes give us that is very difficult to replace in vanilla javascript is a semantic construct that is easy to statically analyzed. In the typed flavors (Flow, TypeScript), I can analyze the interface of plain objects, but not in vanilla JS. Part of why React using ES6 classes can be useful. Thats a great benefit, but Im not sure it's worth the trouble.

styfle 8y ago
> There's very few things JS classes can do that ES6 modules/named exports along with closures returning plain objects can't do better That's a really good point. I was about to disagree with you but then I created a thought experiment. Thought Experiment: I wonder what the JS landscape would look like if ES6 Modules were introduced as part of ES5 about 8 years ago? I could definitely see how that would make classes fare less appealing if we already had a great module system (sure CJS existed but browser didn't support it). Looking at the timeline of when these features were implemented in all major browsers: * ES6 Class[0]: implemented 2.5 years ago * ES6 Modules[1]: implemented 1 month ago [0]: https://caniuse.com/#feat=es6-class https://caniuse.com/#feat=es6-class [1]: https://caniuse.com/#feat=es6-module https://caniuse.com/#feat=es6-module
- shados 8y ago