I believe the primary reason is because JavaScript is fundamentally different from the imperative and class-oriented languages that most programmers are familiar with. At its heart are two radically different paradigms.

The Two Pillars of JavaScript

Prototypal Inheritance Functional Programming

I gave a talk on prototypal inheritance at Fluent Conference, 2013: “Classical Inheritance is Obsolete: How to Think in Prototypal OO”. You should watch it before you continue with this article.

Not convinced? Mattias P Johansson posted an entertaining video today which beautifully illustrates the gorilla banana problem with murderous robot dogs:

Classical inheritance creates is-a relationships with restrictive taxonomies, all of which are eventually wrong for new use-cases if they are continually used and evolved. But it turns out, we usually employ inheritance for has-a, uses-a, or can-do relationships.

Composition is more like a guitar effects pedalboard. Want something that can do delay, subtle distortion, and a robot voice? No problem! Just plug them all in:

const effect = compose(delay, distortion, robovoice); // Rock on!

When would you want to use class inheritance? For me, the answer is simple: “Never.”

Composition is:

Simpler

More powerful

More flexible

More extensible

Better suited to agile development

Introducing Stamps

Stamps are composable factory functions. I created stamps as an experiment for the O’Reilly book, “Programming JavaScript Applications”. It all started with this interesting challenge:

There is sugar for faking classes coming to JavaScript (I strongly discourage using it). What would it look like if we created sugar for prototypal OO that supported all of the best features JavaScript has to offer?*

The result of that exploration was (as far as I know) the most popular prototype-based inheritance library for JavaScript: Stampit.

The idea seemed to resonate with people, and it wasn’t long before spinoff libraries started to emerge. Notably, Tim Routowicz wrote the excellent React Stampit library for composable React components.

There was just one problem with React stamps: Because they were designed specifically for creating React components, the API was changed to serve that purpose better. React stamps and stampit stamps couldn’t be composed together! Oops.

Around the same time, the Stampit community began to speculate about the idea of introducing syntax into the JavaScript specification itself to support stamps. If that happened, how would those stamps interoperate with React stamps or Stampit stamps?

Today, I’m proud to announce that we’ve been working on a specification that will unite all compliant stamp implementations: The Stamp Specification: Composables. We have three implementations currently in progress:

A reference implementation with a test suite for implementors

with a test suite for implementors Stampit 3.0 , with a compatability layer for the Stampit 2.0 API

, with a compatability layer for the Stampit 2.0 API React-Stamp

We’ll be working on these implementations in the coming weeks. The goal is to have them done in time for an official announcement and training masterclass at WebDirections in Sydney Australia, October 27th, 2015.

This is my official invitation to you. Come hear the official release announcement and get a full day of hands-on-training in the Two Pillars of JavaScript using the new Stampit 3.0 and React stamps.

Bonus: You’ll deepen your understanding of functional programming, too.