4 ms·

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 t

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.

Klathmon 10y ago
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.