1. Objects without classes

(and prototypal inheritance aka OLOO — Objects Linking to Other Objects)

  1. Lambdas (with closure)

Brendan Eich didn’t invent either of the pillars, but JavaScript exposed the programming masses to them.

Constructors violate the open/closed principle because they couple all callers to the details of how your object gets instantiated. Making an HTML5 game? Want to change from new object instances to use object pools so you can recycle objects and stop the garbage collector from trashing your frame rate? Too bad. You’ll either break all the callers, or you’ll end up with a hobbled factory function.

If you return an arbitrary object from a constructor function, it will break your prototype links, and the this keyword will no longer be bound to the new object instance in the constructor.

It’s also less flexible than a real factory function because you can’t use this at all in the factory;

If a caller forgets new and you’re not using strict mode or ES6 classes [sigh], anything you assign to this will pollute the global namespace.

Factory functions are simply constructor functions

minus the new requirement

minus global pollution danger

minus awkward limitations (including that annoying initial capitalized letter convention).

JavaScript doesn’t need constructor functions because any function can return a new object. With dynamic object extension, object literals and Object.create(), we have everything we need — with none of the mess.

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” ~ Joe Armstrong

The coupling between a child class and its parent is the tightest form of coupling in OO design. That’s the opposite of reusable, modular code.

the duplication by necessity problem

ES6 classes don’t fix any of these problems. ES6 makes them worse, because these bad ideas will be officially blessed by the spec, and written about in a thousand books and blog posts.

The class keyword will probably be the most harmful feature in JavaScript.

These problems have a multiplying effect as your application grows

I was working on a library to demonstrate how to use prototypal inheritance for my book, “Programming JavaScript Applications” (O’Reilly), when I settled on an interesting idea: a factory function that helps you produce factory functions that you can inherit from and compose together. I called the composable factories “stamps,” and the library, “Stampit.”

Stampit isn’t the only alternative, of course. Douglas Crockford doesn’t use new or this at all, instead opting for an entirely functional approach to code reuse.

Other good alternatives include making better use of JavaScript modules as an alternative to inheritance

simply cloning objects by copying properties from a source object to a new object (e.g. $.extend(), \_.extend(), etc…).

The copy mechanism is another form of prototypal inheritance. Sources of clone properties are a specific kind of prototype called exemplar prototypes, and cloning an exemplar prototype is known as concatenative inheritance.

Concatenative inheritance is possible because of a feature in JavaScript known as dynamic object extension: the ability to add to an object after it has been instantiated.

The seminal “Design Patterns” book by the Gang of Four is built around two foundational principles:
Program to an interface, not an implementation,” and

favor object composition over class inheritance.”

new considered harmful

inheritance considered harmful

super is a code smell

Douglas Crockford got Object.create() added to the language so he wouldn’t have to use new.

Kyle Simpson coined the term OLOO (Objects Linked to Other Objects) to clarify the distinction between prototype delegation and class inheritance.

Classical Inheritance is Obsolete - How to Think in Prototypal OO on Vimeo

How not to do inheritance.

Child needs to know about implementation of parent class.

Prototype is just working sample.

Three kinds of prototypes.

Delegate prototype

Delegating property lookup to another object.

Flyweights object for free

Cloning / concatenation

Existing sample object can be copied.

Great for mixing or default state.

Functional inherence

Not really type of prototype, but can be used like that

For data privacy and encapsulation.


Example of these techniques - StampIt.


Slay'n the Waste Monster by Colt McAnlis (#perfmatters at SFHTML5) - YouTube

Static memory Javascript

JS Objects: Inherited a Mess

embracing that JS has "behavior delegation" (merely delegation links between objects) fits naturally with how JS syntax works, which creates more sensible code without the need of helpers.

year 2013: Haskell people are still writing monad tutorials, JavaScript people are still trying to explain inheritance.

OO-helper libraries are different: they're going to great lengths to hide the true nature of JavaScript's OO mechanisms,

One of the most common metaphors used in traditional class/inheritance OO is that the class represents a "blueprint" for a house to be built, but once you instantiate that class, you are basically copying all the characteristics from the blueprint into the actual built house.