Totally agree with the other response. This absolutely was not standard before class syntax was introduced. Use of constructors, new, this, etc. was the standard - class was essentially just a back port, adding syntactic sugar on top of the prototype design that was inherent to JS from the beginning. The only time I saw something like this was just from people that didn't really "get" or understand inheritance or OOP.
I learned how to do this shortly before JS added class syntax. While the class syntax is more ergonomic, I appreciate how this technique allows all standard OOP features and it emerges only from first-class functions and objects.
The new `class` syntax is just sugar on the ordinary prototypal way in which JS developers have created "classes" for ages (functions which return themselves as objects.) It just makes the code you have to write a little prettier to look at.
This is how everyone wrote classes in JS[1] before the class keyword was added. Most people didn't want to futz with constructor functions and prototype chains. Eventually a class keyword was added to the language.
"Having to write:
this.progressBar.addEventListener(this.handler.bind(this));
is much worse compared to:
progressBar.addEventListener(handler);"
If handler is declared as:
class Foo {
handler = () => {
// handle
}
}
Then there's no need to bind it to this when using it later.[2]
You can just write
this.progressBar.addEventListener(this.handler);
Additionally if handler doesn't reference any other class properties and isn't referenced outside the class, it can also be a function in the module.
I'm not sure that I agree that it was a shortcut for the original creators or older users of JS. Lots of people (myself included) built stuff using self-style prototypical inheritance and argued against adding Java-style classes and inheritance, since they pollute the cleaner prototypical model with a bunch of inconsistencies (not necessarily worse, just inconsistent). We only really lost that argument with ES6 about 4 years ago.
Even using Class syntax you're still locked into prototypical inheritance model. There is no classical inheritance in JS. (Probably a backward step in UX to call it "Class")
> Classes are pretty nice. It's a syntax sugar which is nicer and easier to understand than using functions and prototypes.
I actually think that this syntax sugar is the opposite of a solution. It has always been tricky getting developers coming in from other languages (mainly C-like, and Java-like) to understand that JS is NOT an object-oriented language, but in fact is a prototypal language.
By adding the class keyword, I think this only confuses those users further.
I believe it's because ES6 "class" syntax is a recently added feature (in programming language years). I use classes in JavaScript a lot, but I have to admit that it's mostly for the cleaner syntax and less for the OOP features.
However I have to admit that I've also noticed the trend and would really like to know if there's another reason behind it.
Yea, when people try to rebuild all the fanciful embellishments of classic OOP GUI programming in JS, they're going to have a hard time. Unfortunately I've had to maintain this kind of code in the past. Don't use 'this'. I'm afraid that the addition of the 'class' keyword in es6 will make this tendency worse in some programmers. Along with block scoping, it's a feature lobbied for by people who don't actually code much JS.
That's a really good point, and it's actually close to the reasoning that `class` stuff was added to JS.
Since everyone was making their own incompatible ones, they decided to standardize it even though it really shouldn't have existed in the language at all.
I don't know, personally I'm "neutrally against" them. I'm not going to be upset if they make it in, but i'm not going to personally use them and I don't really feel they are needed as the problems they solve can be better solved by other methods/architectures (some of which admittedly aren't in browsers yet).
That being said, i'm really hoping that the opponents of it come out in january and explain their reasoning.
Yeah: in a very real sense the "original sin" here was introducing (nay: forcing) class syntax to JavaScript, a language which at its core doesn't even naturally use/model classes (as it was designed around prototypes); all of this other complexity is the language falling downhill in an attempt to merely regain functionality for this new syntax that was previously trivial when you simply assigned "methods" directly to your prototype with the = operator (and so making it obvious where you would add a normal function call to functionally compose behaviors instead of needing a "decorator").
This doesn't do a good job of supporting its thesis. The new syntax does in fact allow most devs who understand "traditional" class based inheritance to use JS the way they expect. The fact that it's implemented in JS is both good and also OK to ignore for most devs.
> JavaScript still only has prototypal inheritance; class syntax is just sugar[1].
Sure, but the patterns you use with the class syntax are incompatible with the patterns you use when using object literals, so libraries pick one or the other, typically the class way.
> Even with arrow functions, which don't change the binding of "this"[2]?
Even with arrow functions, `function` still exists ands is more frequently used.
> Trying to access a nonexistent variable throws a ReferenceError[3].
Yeah, but why did they switch from `React.createClass({..})` to the class syntax? Classes are terrible in JS, they're not even native JS, it doesn't fit in JS. This change alone has brought more and more OO JS code.
Switching from writing classes in other languages to using the JS prototype made writing object oriented code more fun and much faster! The prototype way was a step forward. I think it's very weird that JavaScript is now planning to introduce classes, and that you guys are so exited about it.
reply