I have to put it that bluntly ... “The author has not the slightest clue what he’s talking/writing about.” Why do I make such a bold and not at all polite statement? The author already entirely disqualifies himself with the following subheading ...

”JavaScript is not an Object-Oriented Language”.

JavaScript by its very core is as object oriented (OO) as can be. Actually it is a multiparadigmatic (dynamically typed, object oriented, prototype/delegation based with functional aspects) programming language (PL). The author might please gather a deeper understanding about what qualifies a PL as OO. In addition of having entities/objects which feature properties and methods it boils down to Encapsulation, Polymorphism and Inheritance. All 3 criteria are equally important. JavaScript covers all of them very well and in a charming way (but in the end also not that unique as some might think).

Encapsulation is achieved by closures which keep local scope “alive”/accessible.

It features Polymorphism at many levels e.g. by overloaded operators (Ad hoc polymorphism), by generic functions (Parametric polymorphism), by late binding / dynamic dispatch (Subtyping).

Inheritance gets covered by a delegation automatism that operates an object's prototype chain.

Thus, the concept of a class is not necessary at all for OOP. Yet building/implementing a class concept upon/into a highly dynamic, prototype based language does not lead to the absurdity of this concept.

And having class available as a convenient tool, there must be very good reason(s) not to use it. One is not using just syntactic sugar over the old days' constructor functions. JavaScript classes nowadays support a bulletproof subtyping (even of all the instantiable build in objects). Why should one voluntarily give away e.g the inheritance/prototypal delegation in comparison to what the author calls “Crockford Objects”.

Let’s look into some of the authors arguments.

Binding … “Binding is an issue that longtime React developers are familiar with in their applications. Objects defined with classes have to explicitly use the ‘this’ keyword.”

Is this just kidding? The misuse of a feature by poorly skilled developers which have to use an almost Domain Specific Language due to working with a framework which always comes with opinionated design choices is not an argument in discussing a language’s core features. The misuse of bind easily can be avoided (including the old school workarounds of self/that). Use bind as a rapier not as a drench cleaning shotgun. Btw … whoever writes code similar to what the author was providing with the class-method’s bind example should be ashamed of calling oneself a JavaScript developer.

Encapsulation … “While it is possible to create private functions inside of a class by using the ‘#’ character, we can not make variables private in JavaScript.”

Again, a sentence like that just shows a profound lack of understanding about how JavaScript actually works under the hood.

But of cause we are now also coming close to the author’s real intention.

If one’s main goal is the creation of objects which each encapsulate data/state entirely and which explicitly feature (just) privileged methods in order to access (get/write) this encapsulated data, then the leanest approach indeed is to write factories which create and return objects each with closure-access.

Of cause one likewise can achieve this with classes, but then again the constructor function was the very factory which created a class instance with access to the locally scoped variables via its privileged public methods. Thus the feature of prototypal methods bound at invocation time is useless for exactly this scenario.

The above’s paragraph already sums up what, at least amongst senior level JavaScript developers, should be common knowledge. The two lightweight but opinionated, error prone and thus misleading articles like the one’s from the author about Crockford Objects in JavaScript and Why You Should Not Use Classes in JavaScript could not cover that. This kind and amount of writing is not needed because it does not make developers which seek for new insides smarter. It just adds to the many misunderstandings and prejudices this language is already suffering from.