I might be talking past you here, but I think promises definitely qualify as a language feature for JS.
Promises get baked deep into API signatures.
Getting the tradeoff wrong leads to the horror of e.g, the situation for years in c++ where every major library had its own competing string class. Even if std::string was not the best possible string class of all possible string classes, just being able to call all the things without wrapping or thunking or templating everything fixed a major source of pain.
We have already seen this in JS to some extent with various libraries offered in versions supporting native or q or bluebird promises. Fortunately JS is a lot more forgiving than C++ in this respect due to its dynamic nature.
Anyway, the fact that they will tend to appear somewhere in API signatures for any large library is why I support native promises as language feature, not tooling.
That's a really good point, and it's actually close to the reasoning that `class` stuff was added to JS.
Since everyone was making their own incompatible ones, they decided to standardize it even though it really shouldn't have existed in the language at all.
I don't know, personally I'm "neutrally against" them. I'm not going to be upset if they make it in, but i'm not going to personally use them and I don't really feel they are needed as the problems they solve can be better solved by other methods/architectures (some of which admittedly aren't in browsers yet).
That being said, i'm really hoping that the opponents of it come out in january and explain their reasoning.
Promises get baked deep into API signatures.
Getting the tradeoff wrong leads to the horror of e.g, the situation for years in c++ where every major library had its own competing string class. Even if std::string was not the best possible string class of all possible string classes, just being able to call all the things without wrapping or thunking or templating everything fixed a major source of pain.
We have already seen this in JS to some extent with various libraries offered in versions supporting native or q or bluebird promises. Fortunately JS is a lot more forgiving than C++ in this respect due to its dynamic nature.
Anyway, the fact that they will tend to appear somewhere in API signatures for any large library is why I support native promises as language feature, not tooling.