如果你計劃構建一個正式的應用程式，那麼在你開始尋找一個圖表庫之前，你需要知道建立好的資料視覺化是一個極大的時間投資。對於資料視覺化你究竟要實現哪些功能，將在哪些裝置上使用，以及你有多長時間來構建應用程式等問題有明確的答案，將幫助對下述指南物盡其用。
跨瀏覽器相容性
無論你是需要一個圖表庫，相容所有瀏覽器相容，還是隻相容現代瀏覽器，這取決於你的目標受眾。如果你是為政府或企業使用者構建應用程式的話，那麼他們很有可能仍然在用舊版本的 IE。所以說，那些僅能在現代瀏覽器內工作的圖表庫可能不是一個好的選擇。
處理跨瀏覽器的相容性問題是非常痛苦的，我認為你選擇的庫應該幫你解決這事。
跨裝置相容性
你的應用程式主要使用在桌面，或者說你針對手機使用者嗎？如果只是為了大屏瀏覽，那麼大多數圖表庫可用於你的視覺化；但如果你想確保在手持裝置一致的體驗，你選擇的圖表庫應該為你負責。最近，改變使用者習慣變得越來越重要。
輸入資料格式
雖然 JSON 正逐漸成為標準格式，尤其是涉及到圖表庫時，但仍有很多情況，你不得不處理 XML。如果你的視覺化需要 XML 格式的資料，那就得了解你的圖表庫是否支援 XML 了。
可定製性
可定製性，至少對於我來說，是最大的決定因素。圖表庫是足夠靈活，以便我能做我想做的事，還是在預設情況下看起來很好，定製仍需“自己動手，豐衣足食”呢？
我喜歡玩弄數以百計的東西，如新增自定義形狀、配置圖例、附加事件（點選、懸停、按鍵），利用資料鑽取（drill-down of data），以及應用主題等。如果你想建立一個漂亮的設計，有一個容易定製的庫將是很好的，這樣你可以根據你應用程式的設計去改造。
可用圖表的範圍
這是一個無需用腦的事。無論你想要建立怎樣的視覺化，它都應該是庫中的一部分。但是對於各種包含集體包（collective packages）的相簿來說，將不是那麼容易，它們將類似的圖表組在一起，如地圖（maps），小工具（widgets）和股票圖（stock charts）。因此，根據不同的使用場景，你可能只想要一個特定型別的圖表， 或者得到一個完整的包。
如果你想要根據可用的圖表範圍比較不同的相簿的話，你會發現這個資源會很有幫助。
學習曲線
一些視覺化庫，如D3.js，有一個陡峭的學習曲線。毫無疑問D3.js是非常強大的，但如果你時間緊迫或者第一次用，我不推薦它。
換句話說，如果你剛開始做資料視覺化且有大量的時間去嘗試，那麼你應該全力去嘗試那些漂亮但需要時間投資的庫。
與其他程式碼的相容性
假想你是一個對 JavaScript 不太熟悉的 PHP 或 ASP.NET 戰神，如果你可以不寫任何 JavaScript 程式碼建立圖表，豈不妙哉？一些庫有免費的外掛和封裝器，幫你生成在瀏覽器頁面上渲染圖表所需的 JavaScript 和 HTML 程式碼。例子：FusionCharts Extensions 和 Highcharts extension。
效能
效能取決於很多因素，如庫的大小，渲染時記憶體使用量，垃圾回收以及瀏覽器重繪的時鐘週期數。我非常看重效能，但僅為效能的優化並不總是好的想法。這聽起來似乎自相矛盾，所以讓我用一個例子來解釋一下我的觀點。
假設你將構建一個用於區域網的儀表板（dashboard）：你認為在這種情況下，使用一個最小的庫有意義嗎？在這種情況下，我會選擇一個基於這裡討論的其他因素最好的庫。節省庫的大小，將是我最不關心的事。
匯出
這一點不適用於所有使用場景，但僅適用於像報告和儀表板（dashboard）這樣的情況。如果你為商業使用者構建一個儀表板，那麼你的使用者可能會希望將圖表匯出到PDF或者圖片。你選擇支援開箱即用的匯出功能的圖表庫會更好。常見的匯出格式有JPEG、PNG、PDF 還有 SVG。
設計與互動
設計不僅僅是一個圖表的外觀，它不僅應該好看（主題、配色），而且應該有好的互動。比如，如果你建立一個扇形圖，那麼在預設情況下，當你點選一個扇形區域時，該區域應該被拉出來（或在其圓周上新增邊框）。不應該需要自定義程式碼。在多序列折線圖（multi-series line chart）上，點選一個圖例圖示時，應該切換相關資料圖。
定價和許可條款
現在，當你購買一個許可證後，絕大多數的庫會分發它們的原始碼，但這並不意味著你可以自由地做任何你想做的。重要的是要知道你專案所需的所有許可權和購買相關許可證。條款和定價取決於像使用者數量，應用型別（SaaS，intranet，web）和伺服器數量等因素。
支援
當你構建一個應用程式時，資料視覺化可能不是你的核心力量。所以當你遇到一個問題時，你可能需要藉助外面的支援來解決它。支援可以來自多種形式，如個人、論壇或者社群，如 StackOverflow。如果你日程很緊，等不了 StackOverflow的答案，那麼在這種情況下，個人支援或專門的論壇將是非常有用的。
就流行的庫而言，大多數常見問題的答案都是很容易獲得的。但是我在測試邊緣多次遇到死角。如果你認為你可能需要專門的支援的話，那麼我推薦你購買一個圖表元件，而非使用一個開源的解決方案（即便它滿足所有其他的需求）。
開源
我熱衷於開源，但我相信它不是一切問題的正確的解決方案。特別是它涉及到圖表的解決方案時，GitHub上有成千上萬小的、開源庫。但你嘗試在專案中使用其中的一個之前需小心謹慎。
我一個朋友，因為他喜歡的幾個功能，曾經在他的商業專案中使用過一個小開源庫。 一年後，當他試圖實現一些高階功能時，他卡住了。當他試圖聯絡庫的建立者時，他才知道這個專案早已被丟棄了。我確信這不會發生在大的開源庫上，如D3.js、Google Charts，morris.js，但最好是考慮這種可能性，而不是後面後悔。
這有一篇文章回答了何時一個商業庫比一個開源庫更有意義。
為了做出明智的選擇，我認為知道所有這些因素是重要的。如果你認為我錯過了一些因素，請在評論中提到它們。
— Merrily
Vikas，你談及了很多重要的點 ，都考慮得不錯。還有一個要考慮的是，資料點的個數以及圖表的個數。一個庫能支撐大量資料點且保持專案所需的互動功能嗎？當一個頁面上有多個圖表時，效能又怎樣呢？
你也提到了互動功能。雖然從圖例切換資料集，點選移動扇形分片，以及深入到圖表的能力是非常重要的，但在實際應用中，這些功能都是相當基礎的。要記住對於資料視覺化應用，考慮真正發揮客戶端互動性的互動，如批註（annotations）和運算元據集，也是非常重要的。
— Merrily