Vue.js（發音/vju？/，類似於view）是壹個用於構建用戶界面的漸進式框架。
妳可能對這句話並不陌生，但妳可能並不真正理解它。我們註意到，在這句話中有壹個作者特別強調的詞——遞進框架。實際上，我們理解了這個詞的含義並理解了這句話，從而理解了Vue的核心概念。
那麽漸進框架是什麽意思呢？在解釋這個詞之前，我們有必要了解“什麽是框架？”[1]
在最初的前端開發中，為了完成某項任務，我們首先使用JS從HTML文件中獲取DOM元素，然後添加事件，最後進行壹系列JS編程操作。我們姑且稱這種開發方法為“DOM stream”。“DOM stream”的開發方法看似簡單實用，但隨著業務需求的不斷變化，妳的麻煩也隨之而來，整個代碼會變得越來越混亂，無法維護。比如假設現在有這樣的需求，有圖。當它被點擊時，點擊次數可以被記錄下來。這似乎很簡單，對嗎？根據上面提到的開發方法，應該很快就會完成。然後，需求發生了壹點變化，需要兩張圖片，當他們被點擊時，他們可以記錄他們的點擊。這壹次似乎很簡單，只需復制並粘貼原始代碼。那麽當這個要求變成五張圖的時候妳會怎麽做呢？最好是簡單地復制和粘貼，這可以完全滿足這壹要求，但您會感到尷尬，因為您的代碼已經變得臃腫，並且有許多重復的過程，但這似乎在您的承受範圍內。此時需求略有變化，點擊量分別由五張照片記錄。但是，單獨列出五張圖片似乎占用了太多空間。現在，只需要存在壹張圖片，並且可以通過選擇按鈕來切換單擊的圖片。這時，妳可能會崩潰，因為要完成這個看似微小的變化，妳最初編寫的大部分代碼可能需要刪除，甚至完全清空，妳可能要從頭開始。更令人沮喪的是，即使妳耐心地重寫了這個需求，壹旦新的需求來了，妳可能不得不重新開始。這只是壹個記錄點擊次數的簡單任務。“DOM Stream”的開發似乎出現了很大的問題，但在實際開發中，復雜的業務邏輯和巨大的代碼量對於“DOM Stream”來說根本無法承受。
為了處理上述問題，開發人員重新組織了代碼的組織結構，並將JS代碼分為三個部分:數據（M）、視圖（V）和邏輯控制（*）。數據板只包含數據內容，視圖板只負責改變樣式，邏輯控件負責聯系視圖板、數據板和相應的邏輯，如下圖所示。這種代碼結構組織的好處是顯而易見的。當需求改變時，只需要改變相應的部分。我們以文中提到的記錄圖片點擊次數的要求為例。這是重新組織的代碼演示。您可以看到這次代碼變得清晰易懂，您也可以想象自己添加壹些需求來查看代碼更改的程度。
事實上，這種開發模式就是我們常說的MV*模式，MVC、MVVM和MVP【2】都是MV*的衍生品。事實上，模式名稱是什麽並不重要。當您現在理解這種代碼組織結構的目的時，您將理解這些模式本質上是相同的東西，因此數據和視圖之間將沒有直接的聯系。事實上，說到這裏，妳應該知道dom流有缺陷的原因。在dom流中，dom實際上被視為壹個模型。我們直接從DOM中獲取數據，然後更改DOM來更新視圖。視圖和模型實際上是混合在壹起的，代碼組織自然是混亂的，難以維護。
而這種MV*代碼組織逐漸演變成了所謂的框架。團隊開發中之所以會使用框架，壹個重要原因是框架預先設定的代碼組織結構使得實際開發項目的代碼有了相對清晰的位置，因此無需擔心因為團隊中某個人的疏忽或獨特的編碼習慣而導致代碼整體混亂。題外話，按照目前對框架的理解，Bootstrap嚴格來說並不是壹個框架，實際上是壹個CSS工具集，主要用於界面美化。而且Jquery不涉及代碼的結構組織，只是簡化了壹些重復性的操作（如DOM操作和Ajax操作等。），並解決了兼容性問題，所以它只是壹個JS庫，以方便操作。
現在，通過MV*的代碼組織，我們擁有了能夠應對不斷變化的需求的健壯代碼。在使用過程中，開發人員逐漸發現，在處理頻繁數據更新的需求時，我們總是在做同樣的工作-獲取DOM並根據新數據更新視圖。這些任務繁瑣且重復，本質上消耗了開發人員的精力。為了解決這個問題，基於MV*模式的MVVM框架誕生了——Knockout。它使用實例的形式將模型層的內容轉移到實例的所謂視圖模型中，並使用綁定方法完成視圖模型和視圖之間的雙向綁定。當視圖模式中的數據發生變化時，視圖也會發生變化，反之亦然。對Knockout的這種描述可能有點抽象，畢竟上面沒有代碼，但至少妳知道Knockout框架可以從數據更新中為我們完成視圖的相應更新，如下圖所示。
您可能想知道為什麽您從未使用過具有如此先進概念和功能的框架，甚至以前從未聽說過它。這是因為淘汰賽提前誕生了。妳還記得本段開頭MVVM框架形成的原因嗎？為了滿足數據頻繁更新的需求，當時大多數前端頁面只涉及靜態顯示和簡單交互，沒有頻繁的數據變更，因此使用Jquery就足夠了。就這樣，當時Knockout並沒有流行起來，但這個框架現在仍然存在，如果妳感興趣，很容易上手。直到近年來，隨著對數據頻繁變化的需求不斷增加，人們開始關註這種自動和新觀點的概念。Vue是繼承這壹思想的眾多框架之壹。如下圖所示，在帶有響應式系統的Vue示例中，DOM狀態只是數據狀態的映射，即UI = VM（State）。當等式右側的狀態發生變化時，頁面顯示部分的UI也會隨之變化。這就是許多人剛開始使用Vue時覺得它很容易使用的原因。但是，需要註意的是，Vue的核心定位不是框架【3】，其設計並不完全遵循MVVM模型。可以看出，圖中只有兩個部分，即狀態和視圖。Vue的核心功能強調從狀態到接口的映射，不註重代碼的結構組織。因此，當僅使用其核心功能時，它不是壹個框架，而更像是壹個視圖模板引擎，這就是Vue開發人員將其命名為類似視圖的發音的原因。
現在讓我們看看“漸進”的含義。如上所述，Vue的核心功能是視圖模板引擎，但這並不意味著Vue不能是框架。如下圖所示，這裏包含了Vue的所有組件。基於聲明式渲染（視圖模板引擎），我們可以通過添加組件系統、客戶端路由和大規模狀態管理來構建壹個完整的框架。更重要的是，這些功能是相互獨立的，妳可以在核心功能的基礎上隨意選擇其他組件，沒有必要全部集成在壹起。可以看出，“漸進”實際上是Vue的使用方式，它也體現了Vue的設計理念。
關於“漸進”的解釋，我在知乎上看到壹個很好的回答，得到了Vue的設計師們的稱贊。這個回答的角度很好，主要是從與React和Angular的對比來看。由於我沒有怎麽用過其他兩個框架，所以我不會隨意評論它們，所以我只摘錄答案供參考【4】。
在我看來，逐步代表的含義是:主張最少。
每個框架必然會有自己的特點，這將對用戶有壹定的要求。這些要求是聲明。主張有強有弱，其強弱將影響其在業務發展中的使用方式。
例如Angular，它的兩個版本都被大力提倡。如果您使用它，您必須接受以下事項:
-妳必須使用它的模塊化機制-妳必須使用它的依賴註入-妳必須使用它的特殊形式來定義組件（這在每個視圖框架中都是不可避免的）
因此，Angular具有很強的排他性。如果妳的應用程序不是從零開始的，而是妳應該不斷考慮是否要與其他東西集成，這些想法會帶來壹些麻煩。
比如React也有壹定的倡導性，其倡導的主要是函數式編程的概念。例如，妳需要知道什麽是副作用，什麽是純函數，以及如何隔離副作用。它的入侵似乎沒有棱角那麽強，主要是因為它是軟入侵。
Vue在某些方面可能不如React和Angular，但它是漸進的，沒有強烈的要求。您可以使用它在原始大型系統的基礎上實現壹兩個組件，並將其用作jQuery。它也可以與它的全家桶壹起開發，並用作棱角；妳也可以使用它的視圖來搭配自己設計的整個下層。妳可以用面向對象的思想和設計模式來代替底層數據邏輯，或者妳可以用函數的方式來使用它。只是輕量級的看法，只做該做的事，不做不該做的事，僅此而已。
我所理解的漸進主義的含義是，我沒有做超出自己職責的事情。
好了，這裏已經解釋了“漸進框架”的含義。現在讓我們回過頭來看看開篇的句子。
Vue.js（發音/vju？/，類似於view）是壹個用於構建用戶界面的漸進式框架。
妳對Vue有不同的感受嗎？現在妳應該知道如何學習和使用Vue了。在學習中，我們不需要壹開始就了解Vue的每個組件和功能，而是從核心功能開始學習並逐步擴展。同時，在使用中，我們不需要取出所有組件，只需使用我們需要的任何組件，並且我們還可以輕松地將Vue與其他現有項目或框架相結合。