我應該使用原生ES6 Promises + polyfill還是自定義Promise庫？

Question

我想將我的代碼切換到Promises / A + API。 我的主要用途是刪除級聯回調

我需要一個解決方案：

• 盡可能地更可持續
• 隨着庫規模的縮小
• 更原生的可能......

解決方案1：原生

我在caniuse http://caniuse.com/#feat=promises上看到ES6的承諾很好地實現了，除了IE ...一個polyfill存在https://github.com/jakearchibald/es6-promise ，所以我可以用它來做IE。

有沒有人已經使用過這個解決方案，它是否可行？

解決方案2：外部庫

我可以使用替代庫，例如藍鳥 ，Q或當 。 使用它們有很大的優勢嗎？

---

更新： @sdgluck與我的第一個想法不同， Bluebird似乎將Promise帶到了更高的水平！ 所以我選擇使用它。

Answer 1

你應該使用本機承諾。

我說你是Q和Bluebird的維護者，你提到過。 我說這是自2013年（開始）以來藍鳥核心，並且多年來一直倡導藍鳥。

我將重申這是藍鳥核心告訴你不要在瀏覽器中使用藍鳥 。

本機承諾的原因是：

• 他們吞下了錯誤 - 如果您沒有附加.catch處理程序，那么您將不知道該錯誤。 （這已得到修復）。
• 它們沒有顯示正確的堆棧跟蹤（已經修復）。
• 它們很慢（這基本上是固定的）。

鑒於這些問題都是固定的，並且所有瀏覽器都實現了承諾 - 您應該盡可能考慮使用本機promises和async / await over promise庫，並根據需要調整輔助方法。

在客戶端，承諾性能無論如何都不是瓶頸 - 而在服務器上 - 當你看到性能問題時，bluebird是一個替代品。 沒有理由使用Q之類的庫或何時使用。 如果你填充原生承諾 - 我建議使用native-or-bluebird （es6-promise吞下上次檢查時的錯誤）。

大多數的API優勢藍鳥有沒有真正相關了-有些東西（像.some ）仍然是好的，但你應該使用async/await流量控制反正 。

---

什么時候應該使用藍鳥？

• 老Node.js（<8）肯定會有很慢的承諾。
• 真正的舊節點（<1.3）承諾吞下錯誤，這是肯定的。
• 在不是Chrome的瀏覽器上 - 原生承諾較慢 - 所以如果你能證明它很重要。
• 在較舊的Chrome中，為了獲得異步堆棧跟蹤。
• 如果你正在編寫一個需要與舊的Node.js版本兼容的庫 - 當然。

Answer 2

如果您正在尋找在瀏覽器中使用的Promise庫，請參閱@Benjamin Gruenbaum的答案 。

---

可用的庫

首先讓我們來看看我們可以使用的最受歡迎的Promise庫。

Library (minified)  | Size*  | Implementation | Native | Client        | Server
---------------------------------------------------------------------------------
native (ES6)        | 0      | Promises/A+    | Yes    | Yes           | Yes
Q                   | 2.5    | Promises/A+    | No     | Yes           | Yes
Bluebird            | 68.4   | Promises/A+    | No     | Bfy*/global   | CommonJS
when                | ?      | Promises/A+    | No     | Yes           | CommonJS
then/promise*       | 4.8    | Promises/A+    | No     | Browserify    | Yes

-

* 大小 ：縮小的大小（KB）

* Bfy ： Browserify

* 注意 ：如果需要支持<IE9， then/promise需要es5-shim 。 ^[資源]

* 注意 ：大多數庫支持在瀏覽器和服務器上進行初始化的多種方法（AMD，Browserify等）。 這不是初始化方法的詳盡列表。

______

尺寸

顯然，使用本機ES6實現在大小方面是最具成本效益的，因為它嵌入在語言中，因此不會產生任何開銷。 其余的應該說明一切。 具有像Bluebird這樣的額外功能的庫相對較大但不夠大，以至於它們應該阻止您使用它們，除非空間是一個主要問題。

______

可持續發展

在持續發展方面，它們仍在定期維護和更新。 然而，這不應該是一個主要問題，因為所有人的核心功能（或者可能更好地說他們公開的核心API ）將保持不變。

在完整性方面：它們都是Promises / A +兼容。 也就是說，他們將所有的行為以同樣的方式。 您可以在任何這些庫中僅使用此規范給出的功能，更改您正在使用的庫，並且應用程序的行為將保持不變。 如果您要使用任何單個庫提供的任何額外功能，則無法再進行此操作。 例如，使用Bluebird的許多便捷方法意味着您的應用程序“綁定”到庫中。

______

“原生岬”

如果這是一個要求，最適合的庫將是沒有庫 。 這當然要求您不需要支持不實現ES6 Promise規范的環境。 否則，沒有明顯的答案。 如果在環境中可用，這些庫都不會使用本機Promise - 它們都實現了自己的Promise功能。 您在這方面的選擇歸結為您認為最適合使用的API。 我個人更喜歡Bluebird因為它提供了許多方便的方法和宣傳 。

______

結論

你應該使用你覺得最舒服的庫。 （在我看來，無論大小。）如果你需要向后兼容性，我建議避免使用需要墊片的庫，只需使用其中一個實現Promises的庫。 如果你需要在瀏覽器中運行Promises，我建議使用一個Promise庫而不是使用polyfill，因為它們提供的功能在你使用Promise時越多越不可取。