編者注：該文章翻譯于 Pier Bover 的“ Vue.js: the good, the meh, and the ugly ”，僅供探討，不代表本站觀點。

使用新的框架和庫總是會讓人興奮，但也有壓力。即使經(jīng)過一些評估，你也永遠不會知道你將會碰到什么樣的意外情況。

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

Tips：以下純屬個人觀點。

好的方面

響應性（Reactivity）

數(shù)據(jù)綁定在前端領域是個大問題�，F(xiàn)在我們更專注于數(shù)據(jù)，而不像使用 jQuery 一樣對 DOM 進行微觀管理。Vue 通過雙向響應數(shù)據(jù)綁定系統(tǒng)巧妙地處理這個問題。

為實現(xiàn)這種響應性，Vue 為狀態(tài)中的每個變量添加了許多 getter 和 setter ，以便它可以跟蹤更改并自動更新 DOM 。這種方法并不完美，我們稍后會再提到。

高可用性（Batteries included）

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

速度

Vue 非�？�。它也許不是最快的，但它的性能表現(xiàn)對絕大多數(shù) Web 項目來說都是頂級的。你上一次需要每秒渲染和更新數(shù)千個 DOM 元素是什么時候？

HTML 模板

這是在 JavaScript 開發(fā)者中具有爭議性的一個話題。無論你喜歡還是不喜歡，HTML 模板已經(jīng)在許多語言中進行了數(shù)十年的實戰(zhàn)打磨，并且是在 Vue 中編寫動態(tài)標記（dynamic markup）的首選。

此外，Vue 也支持 JSX 。

其他

• HTML、CSS 和 JavaScript 的單個文件組件。

• 輕量。大約 20KB（gzip）。

• 高可擴展（mixins、插件等）。

• 文檔完善（除了下面提到的一些例外）。

• 可逐步采用，甚至用作 jQuery 的替代品。

• 易于上手。

呃……不怎么樣的

組件模板（Component boilerplate）

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

Vue 組件是使用對象創(chuàng)建的，這是定義組件函數(shù)的示例：

export default {
 methods: {
  increment () {
   this.count++;
  }
 }
}

你將為計算屬性、組件狀態(tài)、監(jiān)視工具等添加類似的模板。Vue 中幾乎所有的內(nèi)容都有自己的特殊語法和更多的模板文件。

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

class {
 increment() {
  this.state.count++;
 }
}

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

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

社區(qū)？聊天室？（Chat based community）

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

聊天很亂，更主要的是聊天的內(nèi)容無法被搜索引擎索引到。同樣的問題（及其相關的討論）注定要一次又一次地重復。

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

沒那么神奇（Not so magic）

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

比方說：

• 響應式系統(tǒng)僅跟蹤一定條件下的變化。不要指望它能提供任何你想要的東西。通常，你可能需要盡可能地簡化和整理數(shù)據(jù)以避免頭痛。當然，這些都在文檔的細則中有進行解釋。

• 過渡系統(tǒng) <vue-transition> 不適用于列表。實際上，你需要使用的是 <transition-group>，它的工作方式略有不同，并且會在 DOM 中引入新元素。此外，有些東西你本期望會是一個已解決的問題，但實際上你必須要自己去實現(xiàn)它。

• 如果你需要組件實例中的 non-reactive 狀態(tài)，你將進入一個未知的領域。

等等。

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

糟糕的方面

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

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

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

這是否意味著驗證邏輯也適用于 Vuex ？狀態(tài)管理器會開始調(diào)解所有應用程序邏輯？

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

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

總結

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

在過去，不同于 React 的過于理想化，我認為 Vue 是一個很實用的庫�，F(xiàn)在的我仍然這么認為，但另一方面，我覺得 Vue 需要在實用主義之上更注重用戶層面的精致、專注、優(yōu)雅和簡潔。

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

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

就這樣。

補充：Vue CLI

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

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

但是，便利的同時往往會帶來更多成本，在我看來，這里的代價是不合理的。 Webpack 并不像很多人說的那么難，創(chuàng)建自己的入門套件可減輕大量配置時間。

當需要的成本低時，定制自己的自定義產(chǎn)品才更有意義。

標簽： 代碼 開發(fā)者 搜索 搜索引擎

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。