關於 Vue.js：那些好的，不怎麼樣的和糟糕的

在幾乎每天使用 Vue 大約兩年後，我和它的蜜月期結束了，我終於可以從一些角度來寫點什麼了。

Tips：以下純屬個人觀點。

好的方面

響應性（Reactivity）

資料繫結在前端領域是個大問題。現在我們更專注於資料，而不像使用 jQuery 一樣對 DOM 進行微觀管理。Vue 通過雙向響應資料繫結系統巧妙地處理這個問題。

為實現這種響應性，Vue 為狀態中的每個變數新增了許多 getter 和 setter ，以便它可以跟蹤更改並自動更新 DOM 。這種方法並不完美，我們稍後會再提到。

高可用性（Batteries included）

使用 Vue ，你無需使用 MobX 或 React Router 等非官方軟體包來處理應用程式的關鍵部分。Vue 提供了 Vue Router 和 Vuex 。這些都是很好的庫，而且是為 Vue 量身定製的。

速度

Vue 非常快。它也許不是最快的，但它的效能表現對絕大多數 Web 專案來說都是頂級的。你上一次需要每秒渲染和更新數千個 DOM 元素是什麼時候？

HTML 模板

這是在 JavaScript 開發者中具有爭議性的一個話題。無論你喜歡還是不喜歡，HTML 模板已經在許多語言中進行了數十年的實戰打磨，並且是在 Vue 中編寫動態標記（dynamic markup）的首選。

此外，Vue 也支援 JSX 。

其他

• HTML、CSS 和 JavaScript 的單個檔案元件。
• 輕量。大約 20KB（gzip）。
• 高可擴充套件（mixins、外掛等）。
• 文件完善（除了下面提到的一些例外）。
• 可逐步採用，甚至用作 jQuery 的替代品。
• 易於上手。

呃……不怎麼樣的

元件模板（Component boilerplate）

從 React 遷移到 Vue ，我似乎有感受到一股清新空氣，不再到處 bind(this) 或 setState（）。好極了！但過了一段時間，我開始質疑 Vue 元件語法的有效性。

Vue 元件是使用物件建立的，這是定義元件函式的示例：

你將為計算屬性、元件狀態、監視工具等新增類似的模板。Vue 中幾乎所有的內容都有自己的特殊語法和更多的模板檔案。

相比之下，Marko 也有相同的東西，但更簡潔：

我的重點不是關於是否要使用類，而是 Vue 使用的是任意物件結構而不是語言特性。

如果你覺得我有點想找事，我不會怪你。 Vue 還提供了基於類的語法，但它實際上更像是事後諸葛亮。

社群？聊天室？（Chat based community）

Vue 社群使用者喜歡在 Discord 上閒聊，這更像是一款專為遊戲玩家社群設計的聊天工具。如果你遇到問題，聊天可能是你最好的選擇，因為官方論壇是一片荒涼的土地，而且你也不敢在 Github 上問問題。

聊天很亂，更主要的是聊天的內容無法被搜尋引擎索引到。同樣的問題（及其相關的討論）註定要一次又一次地重複。

這種使用聊天來解答問題的趨勢正困擾著開源專案，我認為它應該停止，根本沒有集體學習作用。

沒那麼神奇（Not so magic）

只要你不偏離正軌，一切都會很好，但過了一段時間你可能會發現 Vue 周圍有很多小小的 ifs 和 buts 。

比方說：

• 響應式系統僅跟蹤一定條件下的變化。不要指望它能提供任何你想要的東西。通常，你可能需要儘可能地簡化和整理資料以避免頭痛。當然，這些都在文件的細則中有進行解釋。
• 過渡系統 <vue-transition> 不適用於列表。實際上，你需要使用的是 <transition-group>，它的工作方式略有不同，並且會在 DOM 中引入新元素。此外，有些東西你本期望會是一個已解決的問題，但實際上你必須要自己去實現它。
• 如果你需要元件例項中的 non-reactive 狀態，你將進入一個未知的領域。

等等。

不要誤會我的意思，這些都不是什麼大問題，但似乎每當你開始動手摸索時，就會出現其它的小煩擾。

糟糕的方面

架構模式不清晰（Unclear architectural patterns）

比如，提一個問題：在元件中還是在 Vuex 中處理 API 請求會更好?

該文件提供了有關如何在 Vuex 中處理 API 邏輯的示例，甚至有一個漂亮的圖表：

這是否意味著驗證邏輯也適用於 Vuex ？狀態管理器會開始調解所有應用程式邏輯？

這些都不是很清晰的問題。大多數人會選擇直接將 non-state 邏輯插入到 Vuex 操作中，或者更糟糕的是，直接插入到元件中，因為 Vue 的主頁上有一段視訊說明：

現在來回答我上面的問題：API 邏輯不應該用 Vuex 或元件編寫。在一些官方程式碼示例中，也有很好的說明。

總結

Vue 的使用率一直在不斷增長，我懷疑這種趨勢會很快停止。 它離 React 還很遠（至少在中國以外），並且還需要與 Angular 競爭第二名。

在過去，不同於 React 的過於理想化，我認為 Vue 是一個很實用的庫。現在的我仍然這麼認為，但另一方面，我覺得 Vue 需要在實用主義之上更注重使用者層面的精緻、專注、優雅和簡潔。

在使用兩年後，我對 Vue 的印象一直是積極正面的。我仍然相信將我的團隊從 React 遷移到 Vue 是一個很好的決定。不是因為 Vue 更好，而是因為它更適合我們。

Vue 能很好地完成了它的“本職”功能，並且在其他人失敗的領域取得了成功，但起碼到現在，客觀來說，我並不認為 Vue 有比你技能雷達中的其他選項有更強或更差。

就這樣。

補充：Vue CLI

上文中沒有提到 Vue CLI ，我想解釋下原因。

Vue CLI 是一個非常方便的腳手架工具。 在即將推出的 3.0 版本中，它將更加出色，因為它是一個完整的專案管理解決方案。

但是，便利的同時往往會帶來更多成本，在我看來，這裡的代價是不合理的。 Webpack 並不像很多人說的那麼難，建立自己的入門套件可減輕大量配置時間。

當需要的成本低時，定製自己的自定義產品才更有意義。