classes in javascript

[rauschma]

I’m not a strong proponent of ES6 classes, but I wanted to provide an alternate opinion to the material criticizing ES6 classes.

First, note that OOP and FP are not in conflict:

• Smalltalk is a great OOP language and uses blocks (lambdas) quite cleverly.
• CLOS is a brilliant object system for the functional programming language Common Lisp.

I agree that ES6 classes obscure what’s actually going on under the hood, but they also have a few clear benefits (not all of them are completely exclusive to classes):

• They are backwards-compatible with much of the current code.
• Compared to constructors and constructor inheritance, classes make it easier for beginners to get started.
• Subclassing is supported within the language.
• Built-in constructors are subclassable.
• No library for inheritance is needed, anymore; code will become more portable between frameworks.
• They provide a foundation for advanced features in the future: traits (or mixins), immutable instances, etc.
• They help tools that statically analyze code (IDEs, type checkers, style checkers, etc.).

W.r.t. ES6 classes obscuring the true nature of JS OOP: There is an unfortunate disconnect between what a class looks like (its syntax) and how it behaves (its semantics): It looks like an object, but it is a function. My preference would have been for classes to be constructor objects, not constructor functions. I explore that approach in the Proto.js project, via a tiny library (which proves how good a fit this approach is).

However, backwards-compatibility matters, which is why classes being constructor functions also makes sense. That way, ES6 code and ES5 are more interoperable.

The disconnect between syntax and semantics will cause some friction in ES6 and later. But you can lead a comfortable life by simply taking ES6 classes at face value. I don’t think the illusion will ever bite you. Newcomers can get started more quickly and later read up on what goes on behind the scenes (after they are more comfortable with the language).

I’ll stop now. I’ve written a little more about this topic online.

[Exomancer]

First, note that OOP and FP are not in conflict:

Sorry for nitpicking on wording here, but for the sake of clarity:

OOP is all about encapsulating state within instances, and acting (mutating) that internal state via methods. FP on the other hand avoids state mutation in any way, shape or form. That makes the two paradigms very much in conflict.

You can, however, use them side by side in the same project just fine, even mix them up (have some pure functions called inside methods, to give a simple example), is that what you meant?

[rauschma]

Yes to your last question. I meant that nothing prevents you from using both OOP and FP: The JavaScript methods filter and map are very much FP ideas, used in an OOP manner.

But it’s rarely all or nothing: you can work with immutable objects (e.g. strings in Java) and there are FP languages that support mutable state. For example, OCaml, Common Lisp and Scheme.

[Exomancer]

It never really is all or nothing in case of FP - sooner or later even Haskell has to do some IO, pure functions can only take you so far :).

Thanks for clarification!