Promise 外部函式庫議題

在 ES6 標準正式定案將 Promise 特性加入後，再加上各家瀏覽器紛紛發佈已附有實作 Promise 特性的新版本後，約莫 2015 年中開始，有許多 Promise 相關的外部函式庫，有逐漸的發佈趨緩，或是停止再維護的現象。

目前唯一還在在更新版本的，就只有bluebird而已。下面分析為何會有這個現象發生，以及到底你是要選擇用原生的 ES6 Promise 就好，還是要使用其他外部函式庫中的 Promise 相關 API 的一些建議。

根據一篇在 2015/4 月網路上的問答為何原生的 ES6 Promise 會比 bluebird 慢而且更耗記憶體的內容，回答的內容是由 bluebird 函式庫的創作者所寫的。當時(2015 初)的原生 ES6 Promise，又慢又耗記憶體的主因如下:

1. 尚未最佳化，實作雖然有也是 JavaScript 程式碼

2. 原生 ES6 Promise 使用非常耗資源的new Promise與 executor 方式來建立根(第一個)Promise 物件

從效能評比來看，當時(2015)的效能評比資料還在這裡。

• 序列執行(sequential): 原生 ES6 Promise 的執行時間需要 bluebird 的 4 倍，記憶體需要 3.6 倍

• 並行執行(parallel): 原生 ES6 Promise 的執行時間需要 bluebird 的 9 倍，記憶體需要 5.7 倍

看到這個結果，當然有很多人會存疑，為何 bluebird 會快成這樣，或是原生 ES6 Promise 會慢成這樣，就算是都用 JavaScript 程式碼實作，這麼大的差距也是很誇張。

實際上會出在設計出發點與本質並不相同，bluebird 以較有效率而且節省資源的方式來設計，不只是原生的 ES6 Promise，其他的函式庫都沒有辦法這麼快又節省資源。根據這篇 bluebird 的 issue中的開發者指出，以 Q 與 bluebird 的設計比較，Q 會慢 bluebird 幾十倍是因為 Q 針對瀏覽器提供某些安全上的設計，bluebird 則是極致的追求執行效率，假設所有程式碼都是在完全可信任的環境例如 Node.js 中執行。或許也因為如此，在網路上很多類似的問答中，通常建議只在伺服器端(Node.js)使用 bluebird，而瀏覽器端建議使用原生 ES6 Promise 或 Q。

當然，經過一年之後的原生 ES6 Promise，其效率與記憶體消耗問題已有了很大的改善，根據最近(2016/7)Chrome 瀏覽器使用的 V8 引擎在版本 53 發佈的消息，目前的原生 ES6 Promise 進行最佳化後，效能改善了 20-40%。也就是說未來的原生 ES6 Promise 在經過最佳化後，與外部函式庫的執行效率並不會相差太遠，這個消息無疑為原生 ES6 Promise 打了一劑強心針。

所以如果你要要使用外部函式庫，其理由可能是以下幾個:

• 為了能使用豐富的 API。效率有可能在將來並不是唯一的重點。

• 資源存取類型的函式庫或模組，現在都會提供具有 Promise 的 API，例如資料庫、檔案處理、網路資源存取的模組。例如MongoDB Node.JS Driver就是雙模式的。有一些 AJAX 的函式庫也都是用 Promise 的架構，例如axios，或是像新式的標準 Fetch API，也是基於 Promise 的。

• 工具類型的函式庫，現在可能也有提供相容於 Promise 標準的物件，例如 jQuery(3.0 之後)。

雖然 jQuery 3.0 中實作了符合 Promises/A+標準的 Promise 物件，但是 jQuery 並非單純用於 Promise 架構的外部函式庫，而且 3.0 也才剛發佈不久，再加上長期以來，jQuery 有很多自己設計的擴充 API，API 的名稱與標準中有些不同。如果你原本就有使用 jQuery，是可以使用它新版本中的 deferred 物件與 Promise 物件的 API，但可能還是需要具備 Promise 的使用基礎知識比較好。

原生 ES6 Promise 會被認為是一個基礎，如果是在很簡單的執行流程，或許就已經夠用了。學習語法和使用方法後，以這個基礎你可以因應不同的需求，使用專屬的資源存取模組(例如資料庫)。而這些專門使用在 Promise 擴充的函式庫，雖然額外提供了更多可使用的 API，但使用它們的情況相信會愈來愈少，這也是為什麼後來這些函式庫都停止維護的主要原因。如果你現在需要在伺服器端(Node.js)中，馬上就要使用高效能或豐富 API 的外部函式庫，那麼有可能 bluebird 會是比較好的選擇。原生 ES6 Promise 仍然需要一點時間，除了它的最佳化尚未完全完成之外，它的 API 的確真的少，面對複雜的應用情況可能會不符使用。