So What is the difference between the terms “thenable” and “promise”?
I think the section you’ve already cited does answer this very well:
- A thenable is an object with a
thenmethod. Any object. - A promise is an object with a
thenmethod (i.e. a thenable) that conforms to the specification.
So far so simple. I think your actual question is: “Why are they distinguished?“
The problem is that by looking at an object you cannot decide whether it is a promise.
You might be able to tell that it is a promise because you can see that its then method is implemented by yourself or someone you trust – the promise library of your choice usually. You would be able to “see” that because the object does inherit from your promise prototype, or you can even compare the method being (referentially) identical to the function you’ve defined. Or any other inspection method that is sufficient for you.
You might be able to tell that it is not a promise because it has no then method.
But what do you do with an object that implements then, but is not known to be a promise? It’s a thenable, and will be handled as such.
The Promises/A+ specification aims for interoperability between promise implementations, and uses the existence of a .then() method for duck typing. It does specify an exact algorithm on how to treat such thenables (that might be promises or at least have similar behaviour) so that you can create an actual, trusted (“known”) promise from them.
Why is it denoted within 2 opening and closing brackets? Is there any convention?
Yes, the ECMAScript specifications use this syntax for internal methods and properties:
The names of internal properties are enclosed in double square brackets [[ ]].
Those properties do not actually need to exist, they’re purely used to describe what should happen – an implementation must act as if it used them. They are totally abstract operations though.