12 月 10 日，第五屆 Vue.js 開發者大會（VueConf 2022）由 Vue.js 官方通過在線直播的方式舉辦。Vue.js 作者尤雨溪發表了題為 《Vue 的進化歷程》 的演講，下面就來看看這場演講的具體內容吧！

庫階段

2013-2015年，可以看做是 Vue 的庫階段。那庫和框架的區別到底是什么？庫更多的是嵌入到已有的體系，只是拿開簡單使用。而框架會定義更加廣泛的一套工程實踐，遵循一定的最佳實踐，用配套的工具去遵循一套完整的規范。所以當時的 Vue 只是一個庫。

庫階段的重要里程碑：

2013.12：發布第一個以“Vue.js”命名的版本（0.6.0），在此之前的版本都叫 Seed；

2014.02：第一次在 HackerNews 上公開發，公開后的第一周獲得了 400+ Github Star；

2014.10：第一次實現 Vue SFC 單文件組件（vueify），使用 Browserify 打包；

2014.11：第一次完全重寫（0.11），考慮如何讓它更適合用在生產環境中。

庫階段的設計重點：

• 基于 ES5 的 getter/setters 和原生 JavaScript 對象實現響應式系統，當時的設計重點就是滿足個人設計和實現上的想法和興趣；
• 基于響應式系統實現模版數據綁定（MVVM）；
• 設計重點就是能像 JQuery 一樣可以直接通過<script>標簽直接引用的簡單庫，這種方式不會對其他方面產生意見和限制。

庫階段的特征：

• Vue 還不算一個框架；
• 當時的 API 受到了 Backbone/Ractive 的影響：

響應式系統和組件實例有很強的耦合，所有響應式的內容都需要通過在this上做操作來實現，這樣的實現比較直觀，容易理解，符合基于class思考的思維模式，但是會影響邏輯復用；

直到 0.11 版本才引入 Mixins（混入）；

• 該階段還在摸索完善模板語法和作用域規則，每個版本的模板語法都會有比較重大的變動，并且作用域規則不是很明確；
• 基于 DOM 的渲染機制：
• 模板和編譯后的 JavaScript 之間沒有對應性，當時的 Vue 并沒有“編譯”過程；
• 當時的 Vue 的實現通過把模板直接實例化為 DOM 樹；
• 遍歷實例化之后的 DOM 樹，在遍歷過程中實現數據綁定；
• 類似于現在 petite-vue 的實現，它是在 Vue 3 之后，重新將 Vue 1 的實現構成一個更輕量的實現，可以將 petite-vue 認為是 Vue 1的一個新的展現， 把 Vue 1 的實現以更現代的方式去提供出來，其更適用于更輕量化的、不需要很多工程化介入的場景。

框架階段

2015-2016 年，Vue 就進入了框架階段，以 1.X 版本為目標。

框架階段的重要里程碑：

• 2015.08：發布第一版 Vue Router；
• 2015.09：基于0.11、0.12版本開始開發 Vue 1.0，主要是完善模板語法；
• 2015.10.26：發布 Vue 1.0，代號為 Evangelion；
• 2015.12：發布第一版 vue-cli，它更像是一個拉模板的工具，將配置好的模板拉到本地；
• 2016.03：發布第一版 Vuex。

框架階段的設計重點：

• 穩定模板語法和作用域的設計：

確定了 v-bind、v-on 和對應簡寫的語法；

第一次引入了 v-for（取代了 v-repeat）；

• 將 Vue 項目的涵蓋范疇擴大到了單頁面應用（SPA）框架
• SPA 路由；
• 狀態管理；
• 工具鏈：實現了單文件組件的熱更新支持和Scoped CSS。

通用框架階段

2016-2019年，Vue 進入了通用框架階段。

通用框架階段的重要里程碑：

• 2016.03：第一次明確提出“漸進式框架”的概念；
• 2016.04：開始開發 Vue 2.0，尤雨溪正式離職開始全職開發 Vue；
• 2016.10.01：發布 Vue 2.0，代號為 Ghost in the Shell；
• 2016.11：發布 Vue 2.1，代號為 Hunter X Hunter，引入了作用域插槽；
• 2017.02：發布 Vue 2.2，代號為 Initial D，SSR 支持基于路由的代碼分割，每個路由的代碼可以懶加載；
• 2017.04：發布 Vue 2.3，代號為 JoJo，SSR 支持基于路由的資源預加載；
• 2017.06：發布 Vue 2.4，代號為 Kill la Kill，SSR 完整異步組件支持，可以在 SSR 應用的任何地方使用異步組件，引入了部分優化的 SSR 編譯輸出；
• 2018.01-08：開發 Vue Cli 3.0，進一步擴展框架的邊界，將工具鏈視為框架的一部分；實現針對 SPA 的高度集成的工具鏈，有插件機制，開箱即用，集成 TypeScript 、單元測試、ESLint 等；

Vue 2.0 階段的設計重點：

• Vue 的第二次徹底重寫，目標是改進代碼的架構，提高其長期的可維護性，目前來看 2.0 版本的可維護性依然是相當可以的；
• 引入了將模板編譯為 Virtual DOM 渲染函數的編譯流程，也就是在 2.0 才引入了“模板編譯”的概念；
• 基于 Virtual DOM 的服務端渲染（SSR），先編譯為 Virtual DOM 的渲染函數，生成 Virtual DOM，再將 Virtual DOM 字符串化，類似于 React 的服務端渲染；
• 基于 Virtual DOM 的 跨端渲染（整合 Weex，NativeScript）；
• 結合類型系統：

在源碼中使用 Flow 定義類型；

直到現在，2.x 版本的 TypeScript 類型定義都需要手動維護，而不是從源代碼中生成的，這也是在 Vue 3 中使用 TypeScript 進行重寫的原因之一。

這個階段的一個重要 demo 就是：vue-hackernews-2.0[1]，在當時這個 demo 有重要的意義：

• 使用 Webpack + SFC + Vue Router + Vuex + SSR 實現；
• 第一個完整展示 Vue 2 SSR 架構的 demo，包含了相關的 Webpack 配置，單文件組件如何針對客戶端和服務端進行不同的編譯配置，如何在重構的架構中使用路由、狀態管理等；
• 利用這個 demo 做了很多 Vue 2 SSR 功能的開發，通過這個 demo 來測 Vue 2 SSR 在實際開發中是否易用；
• 這個 demo 更重要的意義是啟發了上層的 SSR 框架，比如 Nuxt.js，Nuxt 最初就參照這個 demo 實現，并吸取了 Next.js 的經驗。

編譯/運行時混合階段

2019年至今，Vue 進入了編譯/運行時混合階段。雖然 2.0 階段引入了編譯，但是 2.0 的編譯和運行時的結合是非常淺的結合，編譯器編譯出 Virtual DOM 渲染函數就到此為止了，編譯器對運行時是怎么樣的并沒有太多概念，而運行時對于編譯器也是沒有概念的，這樣很多優化空間就被浪費了。所以 3.0 階段的主要目標就是讓編譯器和運行時都屬于框架的一部分，它們本身就是耦合的。 在耦合的前提下，讓編譯器為運行時提供更多的信息，讓運行時知道編譯器提供的信息。

編譯/運行時混合階段的重要里程碑：

• 2018.09：在 Vue.js London 宣布 Vue 3 的開發計劃；
• 2018.09 - 2019.05：調研階段；
• 2019.05：實現基于編譯優化 Virtual DOM 性能的新策略；
• 2019.08：提出 Composition API RFC；
• 2020.01：發布 Vue 3.0 alpha 版本；
• 2020.04：發布 Vue 3.0 beta 版本，引入了完全優化的 SSR 編譯輸出，如果組件是用模板寫的，那它的 SSR 編譯輸出不存在任何 Virtual DOM 的開銷，所有能做成字符串拼接的地方都做成了字符串拼接；
• 2020.04 - 2021.02：繞道開發了 Vite。
• 2020.09：Vue 3.0 穩定版正式發布；
• 2021.06：發布 Vue 3.1 版本，提供 Migration Build，使用可以兼容 Vue 2 的用法讓用戶更方便的升級；
• 2021.08：發布 Vue 3.2 版本，引入了 <script setup>。
• 2022.01：Vue 3 正式切換為默認版本，此時 Vue 3 框架范疇內的工具都準備完畢；
• 2022.02：發布全新的 Vue 3 文檔；

Vue 3.0 重構初期的重心如下：

• 提高瀏覽器的最低支持要求，使用現代 ES 語法和功能；
• 全面提升系統；
• 改善類型系統的整合；
• 改善在大型應用中的可擴展性。2018年慢慢開始有有較大型企業、項目開始使用Vue，讓 Vue 遇到了新的挑戰，在實際的場景中，之前的 Vue 設計在比較大的團隊協作的場景中存在可維護性上的問題，希望在 Vue 3 中找到這些問題的解決方案。

Composition API 的意義：

• Vue 的用例越來越多地進入企業、大型項目領域；
• Options API 在可擴展性方面有明顯的上限，對于重構龐大、臃腫的組件有很大的難度，不能輕松的進行邏輯的重新組織。而 Composition API 對邏輯的可維護、組合、復用提供了很好的解決方案；
• 因為 Composition API 更多的依賴函數調用，所以對類型系統更友好；
• 提供靈活且可維護的邏輯組合/復用。

Vite 的意義：

• Vite 大幅優化了開發體驗；
• 將和框架沒有耦合的工具鏈職責剝離，交給一個更大的社區去維護，這樣也會樣 Vue 的體驗變得更好；
• 減少 Vue 本身的框架范疇和維護負擔：Vue CLI -> create-vue

Vue 3 目前定義的框架范疇：

• 核心（編譯器 + 運行時）
• 文檔
• 工具鏈（create-vue）
• SPA 路由（React Router）
• 狀態管理（Pinia）
• 瀏覽器開發工具（vue-devtools）
• IDE 支持（Valar）
• TypeScript 支持（vue-tsc）
• 靜態分析（eslint-plugin-vue）
• 單元測試（@vue/test-utils）

整體趨勢就是向編譯/運行時混合模式進化：

• 同一份模板，不有得編譯輸出：

在瀏覽器中：輸出高度優化的 Virtual DOM 渲染函數；

在 SSR 中：輸出 buffer + 字符串拼接；

將來：Vapar mode（不依賴 Virtual DOM 的渲染代碼，獲得更好的性能）

• 在單文件組件中引入更多的語法糖：
• <script setup>；
• v-bind()：實現動態 CSS 的綁定；
• Reactivity Transform；

現狀

• 社區現在仍然處于 2 -> 3 的過渡階段；
• 2022年6月發布了 Vue 2.7，進一步彌補了 2 和 3 之間的斷層，提供了一個 2->3 更緩和的升級流程。不過，如果現在的 Vue 2 項目很穩定，沒必要為了升級而升級；
• 基于目前的 npm 數據：超過 30% 的項目在使用 Vue 3，大概 25% 的項目在使用 Vue 2.7，所以有超過一半的項目已經可以使用 Composition API 和<script setup>，整體的過渡情況比較樂觀。

展望

Vue 團隊接下來的工作會以 API 的穩定性為優先，重點會放在不影響使用方式的改進上。不計劃引入像 React Server Components 這樣需要和服務器強綁定的特性。

• 短期：

穩定 Reactivity Transform / Suspense，從實驗特性變為穩定特性；

Vue 3.3 的重點是 SSR 的水合性能改進，提供以異步組件為邊界的懶水合和按需水合。

• 中到長期：
• Vapor mode（受 Solid 啟發的模板編譯策略），明年 Vue 團隊會更新更多相關信息。

關于 Vapor mode：

完全一樣的模板/組件語法可以編譯成完全不一樣的輸出，這個輸出不再依賴 Virtual DOM 運行時，而是針對 Web 性能進行特化，可以提供極致的性能和內存占用，還可以在一些情況下做零成本組件抽象，即當組件只使用了基本的 API 時，將它編譯成一個不需要組件實例的狀態，這樣就可以節省一定的組件實例開銷。

Vapor mode 的使用方式上，可以將它無縫嵌入到現有的應用中，可以兼容基于 Virtual DOM 的第三方庫。如果是全新的項目，可以啟用 Vapor-only，這樣就再兼容 Virtual DOM，丟掉了相關的運行時，適合對性能有極致要求的場景。

相關資料

[1] vue-hackernews-2.0: https://github.com/vuejs/vue-hackernews-2.0