Introducing
the Stamp Specification
Move Over, `class`:
Composable Factory Functions Are Here
In 2010, the JavaScript world looked much different. Developers were beginning to awaken to the power and potential of JavaScript, and as we did, the number of companies building JavaScript applications hit a critical mass. Suddenly, JavaScript wasn’t just the web browser scripting language. JavaScript was a serious, respected tool for real application development.
Around that time, I started doing a lot of interviewing to hire developers. That’s when I noticed a huge problem that has only grown in the time since:
Lots of people know a little JavaScript, but almost nobody really understands the nature of JavaScript, and what makes it special and uniquely suited to be the language of the web platform.
There is a skills gap in the general software development marketplace, but the JavaScript gap is even bigger. Grand-canyon big. The number of people who really understand JavaScript compared to the number of people using JavaScript is a joke. Douglas Crockford calls JavaScript “the world’s most misunderstood programming language.” I agree.
“JavaScript is the world’s most
misunderstood programming language.”
~ Douglas Crockford
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
- Stampit 3.0, 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.
Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript Universal App Development with Node, ES6, & React”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.
He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.
