“Class” syntax in JavaScript is not awesome.
Use with caution, favour composition over inheritance, don’t inherit more than once.
JavaScript is not Java.
“Class” syntax in JavaScript is not awesome.
Published
“Class” syntax in JavaScript is not awesome.
Use with caution, favour composition over inheritance, don’t inherit more than once.
JavaScript is not Java.
John Hardy Developer 
I think classes were a mistake in Python. As for JavaScript, not having classes is one of the great things about it. Class functionality seems to break functional programming.
LikeLike
As discussed previously there are weak arguments for OO in components. Even weaker ones for data. Nothing that composition can’t do better so it’s a pity that tc39 caved on the “class” keyword. The only thing useful that OO offers functional programming is late bound polymorphism which is useful in dynamic typed languages.
LikeLike
I don’t think it’s worth the cost.
OO classes come with magic functionality; getters & setters, constructors and destructors, polymorphic methods, operator overloading, etc.
A simple dynamic language with built in generic data types (null, simple types, lists, maps) really lends itself to functional programming with duck typing; you can reason about what a given value might be, but there’s enough complexity to make what you need.
But with full OO classes, it tends to be impossible in general to know what a value might do if you push it and prod it a bit. So you lose something.
And, methods tend to be shit in a functional context. Does it drag the whole object along with it? etc.
Also, as soon as you have classes, every time you touch them, everything seems to become infected; all your libraries and frameworks. Before long, you can’t not use them; you’ve become Java. It looks like that’s already happening in JavaScript, looking at that article’s discussion of React.
LikeLike
Yes OO is basically a flawed model for controlling complexity. It tries to ensure integrity through data hiding and encapsulation. This is not actually a good way to do it when everything is mutable and inheritance exponentially increases complexity. The way you know that FP is better than OO is when FP shows you how to delete code while still maintaining functionality. OO is all about adding code and never deleting any.
LikeLike
Mutable OO is problematic but there is a case for immutable objects such as containers with polymorphic methods as the way to access the value within. Anything that transforms the value however results in a brand new immutable object. Mutability is forbidden.
Immutable objects are a common way of implementing of monads in JavaScript because the language doesn’t have typeclasses and pattern matching unlike languages like Haskell or Ocaml.
Here is a pretty good run down of monadic JavaScript. You’re already using something similar to monads when you use promises or any other container type of object.
https://github.com/getify/Functional-Light-JS/blob/master/manuscript/apB.md/#appendix-b-the-humble-monad
LikeLike
I wish they’d skipped classes (and the destructuring sugar) and added decimal arithmetic instead.
LikeLike
mathew murphy do you mean github.com – tc39/proposal-bigint? This was added to the language this year.
LikeLike
Mkm
LikeLike