Comment by Klathmon | Hacker News Reader

Comment by Klathmon | Hacker News Reader

Parent Full thread

Because a tool can be replaced, it can be upgraded, it can have multiple competing implementations that will work across browsers and even languages. Tools can be easily deprecated, removed, changed, fixed, and improved. Tools can be made much simpler and faster by only supporting a single use case, or they can be slower and more complicated but solve them all.

Language features are much more set in stone, mostly because breaking backwards compatibility in a language implementation is not something to take lightly. You don't have the option of only supporting a subset of a feature for a massive speedup, it's all or nothing (for an example of this, see benchmarks between the native .forEach and alternate implementations which are much faster but cut some corners).

JS is still feeling the pains of mistakes made in it's early days, and throwing more features which aren't fully thought out into the language is a recipe for disaster. (This does not mean that I think every feature added to JS is perfect, or even warranted. It's just the reasoning for not trying to add some features which could be better addressed with tooling)

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.

Fair point. Thanks for your input.

Reply on news.ycombinator.com