0
私はjs devではなく、q.jsと約束の背後にある歴史/関係を本当に知っていません。私がMozilla Developer Networkのドキュメントを見ると、ネイティブのjavascript Promiseの実装がq.jsのやり方を多かれ少なかにしているように見えます。 q.jsは約束の早期実施でしたか？今日はそれが必要ですか？javascript Promise実装に含まれていないq.jsを追加していますか？
今私はq.jsを使用して、いくつかの（4-5歳）のコードに取り組んでいたとき、私は私が使用していると仮定していたコードを追加していたとき、私は常に、q.jsへの呼び出しで満たされ、私のコールスタックを参照してくださいネイティブプロミスの実装。私はプロジェクトからq.jsを削除したいと思いますが、私はPromiseのネイティブ実装にどのような価値が追加されているかを十分に理解していません。 Promiseの実装がないブラウザをサポートするだけですか？それとも何か他のことが起こっていますか？
ネイティブプロミスのサポートは、後で行われました。多くの "カスタム"約束ライブラリはそれ以前にリリースされました。 – marekful
作業している現在のコードについて、より多くの背景を理解することは役に立ちます。通常、qなどのライブラリは、xhr呼び出しと約束の処理を簡素化するのに役立ちます。私は自分自身も最近のjs開発者ですが、私が正しくリコールすれば、ネイティブの約束はいくらか新しいものであり、以前の開発者によると、最初にリリースされたときに採用したものではありませんでした。私は彼らがさまざまなブラウザのバージョンとの互換性のために既存のライブラリを使用している可能性があると思います。質問に答えるために、qはネイティブの約束を抽象化することだと信じています –
プロミスはES6の新機能ですが、その前に「コールバックの地獄」や「運命のピラミッド」の問題を扱う多くのソリューションがあります非同期プログラミングの場合、qは最も有名なものです。 ES6より前のES標準のみをサポートするコンテナ（ブラウザ、ノード、jsなど）がコードで実行されないことを保証できる場合は、間違いなくそのような「移植」作業を行います。 – tibetty