From JavaScript docs JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.
But again with Closures, I don't think we need class at all, and I think class is step backwards. I'm not just pulling this out opinion out of no where. I'm of the Douglas Crockford school of JavaScript. Use a subset of everything, strip it to the bare minimum, aim for readability and not clever. Class is too clever of a thing in my mind, because it isn't actually a class in the way that OO languages actually use class. I have to use it now, everything modern and new uses it, but there was a much better way.
Interfaces however, are fantastic, and something we should use everywhere. So it's not all bad.
I really think classes are an error in JS, and we should be using a paradigm that reflects prototypal inheritance and how it works. IE, your objects are composed, dynamic, living things, and not dead rigid objects, in a rigid hierarchy that we never define correctly. Prototypes work really well with composition style of development, where you have a thing that isn't a single type, but many types or no types.
I keep hearing the scaling argument - but I honestly have my doubts. I've worked on big complicated projects in both dynamic and strictly typed languages, and I find it way easier to fix problems and refactor. I'm not against typing it all, but I do think it's way too overused, and eventually it creates a mess of boilerplate that is hard to reason about. Your mileage will vary.
This reminds me of circular arguments with regards to something like Wikipedia. Harder to screw up, or harder to change? pick one.
I pick easy to change every time, for the reason that you pointed wisely out : you can't control what other people write, only what you write.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I can't go point by point on this,
From JavaScript docs
JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript.But again with Closures, I don't think we need class at all, and I think class is step backwards. I'm not just pulling this out opinion out of no where. I'm of the Douglas Crockford school of JavaScript. Use a subset of everything, strip it to the bare minimum, aim for readability and not clever. Class is too clever of a thing in my mind, because it isn't actually a class in the way that OO languages actually use class. I have to use it now, everything modern and new uses it, but there was a much better way.
Interfaces however, are fantastic, and something we should use everywhere. So it's not all bad.
I really think classes are an error in JS, and we should be using a paradigm that reflects prototypal inheritance and how it works. IE, your objects are composed, dynamic, living things, and not dead rigid objects, in a rigid hierarchy that we never define correctly. Prototypes work really well with composition style of development, where you have a thing that isn't a single type, but many types or no types.
I keep hearing the scaling argument - but I honestly have my doubts. I've worked on big complicated projects in both dynamic and strictly typed languages, and I find it way easier to fix problems and refactor. I'm not against typing it all, but I do think it's way too overused, and eventually it creates a mess of boilerplate that is hard to reason about. Your mileage will vary.
This reminds me of circular arguments with regards to something like Wikipedia. Harder to screw up, or harder to change? pick one.
I pick easy to change every time, for the reason that you pointed wisely out : you can't control what other people write, only what you write.