This article is not really very good at describing why classes in JS are a bad idea. So, instead of kicking a lame puppy, let’s discuss why we think or don’t think that JS classes are good.
Here are some reasons against that I’ve either given or heard, regardless of coherence:
JS is a prototype language, and using classes pollutes this.
One of the counterarguments, though I have no real opinion on which side here has the better arguments, is that in practice much JS code uses the prototype mechanism to produce class-style OO anyway. And that in fact this is so widespread that JS runtimes detect these latent classes for optimization purposes (I believe V8 pioneered this, borrowing some old techniques from Self compilers). So, one argument goes, one might as well reify these kinds of classes on the programmer side too, rather than making people simulate class-based OO through prototype-based OO.
I wrote the page in a bad, coffee-deprived stupor and the arguments you made here really are a lot more clear than what I put down. I reworked the page a bit, but if you interested I would love a pull request to make the page better.
So the argument comes down to “we think class is too complicated and prefer using prototypes directly with function, like the old days”?
This screams “get off my lawn and leave me alone,” but is otherwise unconvincing, which seems quite opposite of other better known Marxist manifestos…
IMO class is not too complicated, but it obfuscates what’s really going on and doesn’t map 1:1 with class-based languages.
Prototypes are incredibly simple. They’re just different.
You know, as a Pole I kind of find using ‘Marxist’ to describe something not related to history tasteless.
“It is wholly wrong to blame Marx for what was done in his name, as it is to blame Jesus for what was done in his.” — Tony Benn, 1982
I’ve been doing a lot of Typescript, and I’ve found that interface is my buddy in most of this. I have pretty much no interest in using class for method resolution, and the data is the data, right?
Granted, I’m mostly doing UI things. Perhaps if I were doing more backend-y, server things this would be more of a painful point. But prototypal inheritance + interface has served me pretty well up to this point. Plus it fits pretty well with the philosophies laid out in Simple Made Easy
At this point I wonder where the demand for class is coming from. It’s pretty simple syntactic sugar to using prototype at this point. One could argue the same about fat arrows too, though…
I may be too immersed in ES6 to be an unbiased observer, but I personally find the class version much easier to read and understand. In addition, the classless version does something subtly different and probably undesired. It returns a generic Object instance instead of an instance of the class expression.
Note: My reply only makes sense when referring to the examples in the original article. Not so much with the updated article.
I’ve been writing in JS for years and it’s been my main working language for the last.. 7 years? The thing I like the least about es6 is the whole fat arrow syntax. It makes things hard to scan, and that makes it bad code IMO. Sure, you save some keystrokes when writing it, but it’s easier to miss when you’re looking through someone else’s code. I don’t think the class syntax is that bad. It’s pretty easily readable.
The examples provided in the link are pretty abysmal and contrived. If you look at real world code using the class keyword, it’s much less goofy.
For fat arrows it’s much more about saner scoping rules than it is about saving keystrokes.
The fat arrow may take some getting used to but wait until you get to savor all those bytes you would’ve lost to function
I’m not sure if they do already, but I’m sure there are minifier flags you will be able to use that will convert them for you. You know, since they make it unreadable anyway :P
Not only that, but “this” sometimes doesn’t change (example: Promises IIRC or maybe it was sockets). I think they should’ve kept .bind/call/apply(this) instead of fat arrows too. They are thinking of replacing bind/call/apply with :: also.
They are thinking of replacing bind/call/apply with :: also
I did not know this, but it’s good. I was actually thinking of doing the same as a babel add-on, glad I had the same syntax in mind, although my semantics are likely different; I want foo::bar === foo::bar, which is exactly why bind is not IMO the correct solution.
foo::bar === foo::bar
Better to have new syntax such as fat-arrows for “sensible this” and “:: for fixed bind” than to change the behaviour of existing code in subtle ways.