11 ms·

Can someone give a good use case for these that can't be easily solved with existing tools? I'm really struggling to find a good example. I seem to have this pr

by BigJono 10y ago

Can someone give a good use case for these that can't be easily solved with existing tools? I'm really struggling to find a good example. I seem to have this problem for a lot of new stuff introduced into Javascript...

skylark 10y ago
Why should you be satisfied with using tools? If the feature is compelling enough, it should be included in the standard library.
- Klathmon 10y ago
  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)
  - skylark 10y ago
    Fair point. Thanks for your input.
  - xyzzy123 10y ago
    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.
- BigJono 10y ago
  To clarify, I was talking about existing tools in the standard library
idbehold 10y ago
Unlike an XMLHttpRequest which can be aborted, the new fetch() API does not provide a way for you to abort the request. This is because there is no standard way to cancel a Promise which is what fetch() returns.
- couchand 10y ago
  So.... we introduced Promises so that we could introduce fetch() that returns a Promise, only to discover that it meant we couldn't get all the other useful behavior of XMLHttpRequest. So while a proposal to add cancelable Promises would fix the inability to abort, we'd still need yet more additions to completely get back to functionality we had previously.
  - idbehold 10y ago
    That wasn't the reason promises were introduced. An XMLHttpRequest can be synchronous which is Bad™ and that is something explicitly not allowed by the Promise/A+ spec which means it will never be something that fetch() could do. The advantage of promises is that they can be `await`ed in the context of an `async` function which takes a lot of the cognitive load off of the developer.
    - Klathmon 10y ago
      Furthermore the `await` syntax is one of the reasons why cancelable promises is contentious. There's no easy way to "cancel" an awaited promise without basically resorting to the .then() syntax.
- Sacho 10y ago
  Can't you use bluebird promises with fetch to add cancellation? I haven't tried it. I suppose you may want abort semantics but those appear to be impossible to implement in a generic way.

by BigJono 10y ago

skylark 10y ago

Why should you be satisfied with using tools? If the feature is compelling enough, it should be included in the standard library.

Klathmon 10y ago
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)
- skylark 10y ago
  Fair point. Thanks for your input.
- xyzzy123 10y ago
  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.
BigJono 10y ago
To clarify, I was talking about existing tools in the standard library

idbehold 10y ago

Unlike an XMLHttpRequest which can be aborted, the new fetch() API does not provide a way for you to abort the request. This is because there is no standard way to cancel a Promise which is what fetch() returns.

couchand 10y ago
So.... we introduced Promises so that we could introduce fetch() that returns a Promise, only to discover that it meant we couldn't get all the other useful behavior of XMLHttpRequest. So while a proposal to add cancelable Promises would fix the inability to abort, we'd still need yet more additions to completely get back to functionality we had previously.
- idbehold 10y ago
  That wasn't the reason promises were introduced. An XMLHttpRequest can be synchronous which is Bad™ and that is something explicitly not allowed by the Promise/A+ spec which means it will never be something that fetch() could do. The advantage of promises is that they can be `await`ed in the context of an `async` function which takes a lot of the cognitive load off of the developer.
  - Klathmon 10y ago
    Furthermore the `await` syntax is one of the reasons why cancelable promises is contentious. There's no easy way to "cancel" an awaited promise without basically resorting to the .then() syntax.
Sacho 10y ago
Can't you use bluebird promises with fetch to add cancellation? I haven't tried it. I suppose you may want abort semantics but those appear to be impossible to implement in a generic way.