與 Natalia Tepluhina 合作的 Smashing Podcast 第 26 集：Vue 3.0 有什麼新功能？

在這個播客集中，我們談論的是 VueJS。 3.0 版本中有哪些新內容，遷移難度如何？ Drew McLellan 與核心團隊成員 Natalia Tepluhina 交談以找出答案。

顯示註釋

• VueJS
• Vue 3 遷移指南
• 娜塔莉亞在推特上
• 娜塔莉亞的個人網站

每週更新

• 設計數字產品頁面的不同方法
  作者：蘇珊娜·斯卡卡
• React Native 應用程序中的單元測試
  作者：財富池地
• Google Analytics 幫助 Web 開發人員進行 UI/UX 設計的 5 種方式
  由克拉拉·布恩孔塞霍撰寫
• 了解 TypeScript 泛型
  由傑米·科克希爾撰寫
• 如何使用面部運動與排版交互
  作者：愛德華多·卡瓦扎

成績單

Drew McLellan：她是一位充滿激情的 Web 開發人員、Google 開發人員專家、會議發言人和作家。 目前她是 GitLab 的一名前台工程師，但作為 Vue JS 核心團隊成員，您可能最了解她。 很明顯，她比幾乎任何人都更了解 Vue。 但是你知道嗎，她曾經教過一隻袋鼠唱歌。 我的 Smashing 朋友們，請歡迎 Natalia Tepluhina。

德魯：嗨，娜塔莉亞，你好嗎？

Natalia Tepluhina：嗨，Drew，這是我姓氏的一次非常好的嘗試。 我需要給你學分。 當他們試圖發音我的姓氏時，這是我從說英語的人那裡聽到的最好的事情之一。 如果你不會說俄語，我想這是不可能的。 正確的發音是 Tepluhina，但這就像，這就是為什麼我通常只是要求人們叫我 Natalia，讓我們停下來。

德魯：好的，我努力了。 但重要的問題是，你在粉碎嗎？

娜塔莉亞：我當然是。

德魯：那很好。 所以我今天想和你談談我們在 9 月份發布的 Vue 3.0 的一些非常令人興奮的消息。 就版本號而言，它是一個主要版本，但它確實是 Vue 的一個大版本，並且已經投入了很長時間，不是嗎？

娜塔莉亞：是的。 我認為我們在 2018 年首次發布了第三版。我認為它是在春季宣布的，真正的工作開始於，我的意思是想法是在春季，真正的工作是在 2018 年秋季開始的。 我認為它是在 2018 年 10 月舉行的倫敦會議上正式宣布的。積極的工作花了兩年時間。 如果你想一想，這很多，之前的版本是在 2016 年發布的。所以這四年的一半時間也致力於 Vue 3 的工作。

Drew：決定需要一個新的主要版本的動機是什麼？ 這是一種有意識的決定，好吧，我們要開發一個主要版本，我們要開發 Vue 3，還是只是一種只需要版本提升的變化的積累？

Natalia：不，我認為創建一個新版本是一個想法，因為有一些非常重要的事情。 因此，首先，有改變反應性的動機。 前一個基於 Object.defineProperty。 它有一些警告，它們都已記錄在案，但仍然存在。 你知道，即使你記錄了人們不應該做的事情，他們還是會去做。 您需要將它們指向文檔。 順便說一句，沒有人會閱讀文檔。 出於某種原因，它只是發生了。 直到你指出人們在它的文檔中不存在它。 不過沒關係。 無論如何，我們都會教你。 所以反應性是其中之一。

娜塔莉亞：表演是下一個。 Vue 2 仍然有並且沒有最差的性能，但是我們有一些關於如何讓 Vue 更快的想法。 對於我們的特定部分，比如說觀眾，使用 Vue 的人來說，也有一個痛點。 那是打字稿。 Vue 2 內部是用 Flow 編寫的，它仍然是強類型的，但是使用 TypeScript 打字是一場真正的噩夢，特別是如果你正在使用我們的狀態管理 Vuex。 這又是一個很大的部分。 最後一個是，我們有點錯過了抽象邏輯的功能，不是組件，而是可組合的邏輯部分。 像函數助手等，但它們也應該能夠包含查看器活動。 一個很好的例子可能是 React Hooks，它們允許你抽象部分功能，而這在 Vue 中顯然是缺失的。 而且我知道現在聽起來像是“你從 React 偷了這個特性”。 事實上不是。 我相信想法異花授粉是我們生態系統中一個重要而美好的部分，它還可以幫助開發人員在收藏夾之間切換，對嗎？

Natalia：所以我們正在開發這些主要功能來創建 Vue 3 作為主要版本。

Drew：現在我認為存在於開源生態系統中的一大優點是來自各種不同項目的大量想法和經驗，並且能夠借用這些想法並從其他項目中藉鑑經驗項目真的是有益的，讓一切變得更強大，不是嗎？

娜塔莉亞：是的。 我認為它的工作方式就像我們在 GitLab 中調用迭代值的方式一樣。 當你想出一個想法時，它永遠不會完美。 它主要是一些非常原始、非常硬編碼的東西。 也許會改變一些東西，但這絕對不是完美的。 你需要對這個想法進行幾次迭代才能使它真正好，甚至不完美，只是好。 並且隨著生態系統中的想法而發生。 有人想出了一個好主意，你就接受它，讓它變得越來越好。 我敢打賭，會有一些東西會從 Vue 中汲取一些想法，也許他們已經從 Vue 中汲取了一些想法，並使其變得更好，這裡沒有什麼不好的。

Natalia：我強烈反對，比如，“你在竊取想法”。 這不是偷竊，這只是異花授粉。

德魯：沒錯，是的。 您提到遷移到 TypeScript，所以現在 Vue 3 本身是使用 TypeScript 編寫的，對嗎？

娜塔莉亞：是的，是的。 相信我，Drew，我正在編寫文檔，關於如何使用 Vue 和 TypeScript 的小文檔。 我當時想，好吧，可能有點像 Vue 2。而且我把文檔過於復雜了，我就像是明確地輸入了所有內容。 看起來不錯，一切都已鍵入。 我可以看到類型，所以我的 ts-link 很開心，到目前為止一切都很好。 然後是我們的一位使用 TypeScript 的開發人員，“你不需要這樣做”。 怎麼樣，怎麼樣？ “你不需要對數據進行顯式類型。 您只需給它一個初始值， ts-link 就知道它的編號。 已經打好了。” 比如，怎麼來的？ “我從文檔中刪除了 90% 的顯式類型。 您真正需要輸入的只有兩件事是組件的代理，以及計算屬性。 他們仍然需要返回類型。 但是其餘的就像是自動鍵入的，只需使用我們稱為定義組件的方法編寫一個組件。 就是這樣。 是打字的。”

納塔利婭：就像，它只是工作。 對我來說，在我過去的經驗中，我經常使用 Angular，我有 TypeScript 的斯德哥爾摩綜合症。 一切都應該明確輸入。 我的意思是，如果你有復雜的類型，當然你需要編寫接口，但這就是 TypeScript 的工作方式。 不過，現在使用 Vue 3 使用 TypeScript 要容易得多。

Drew：太好了，所以這對 Vue 核心項目和使用 Vue 構建應用程序的開發人員都有好處，因為他們現在可以在他們的應用程序中很好地使用 Vue，而 2.0 和任何版本都無法使用 TypeScript 2.0 這麼容易。 熟悉 Vue 社區的人會知道，Vue 的創建者 Evan You 仍然非常積極地領導該項目。 核心團隊如何運作？ 在開發過程中它是如何構建的？ 不都是埃文嗎？

Natalia：這是一個很好的問題，Drew，因為多年來，從字面上看，人們一直在談論 Vue，我引用這個，我會聽起來很苛刻，但抱歉，它就像，“一個中國人的框架，甚至像中國人的框架” . 我的意思是，即使是 Vue 1.X，也已經有了一個團隊，並且 Vue 2 背後有一個大團隊，而 Vue 3 背後的團隊更大。問題是當我們談論 Vue 時，我們都有不同的責任。

Natalia：有一些人在開發 Core，這不僅僅是 Evan 本人，他正在做 Vue Core 的大部分工作，當然，他也在領導這個項目。 但也有人在 Vue Core 工作，他們的貢獻絕對是無價的。 還有一些新人也加入了 Vue 團隊，他們在 Core 工作。 還有一些較小的團隊在研究生態系統，有些人在研究 Pure Router，比如 Eduardo，有些人在 Vue CLI、Vuex 和文檔方面工作。

Natalia：有一個完整的團隊在處理文檔，因為我們認為文檔很重要。 目前在我們的網站上有，我認為 21、20 或 21 人，總是錯過計數，屬於核心團隊，但這不是一個靜態列表。 因為我們，我們顯然沒有招聘，我們是一個開源團隊，這不是有償工作。 但是我們相信，如果有人對 Vue 生態系統的任何部分做出了很大貢獻，那麼當人們已經完成核心團隊成員的工作時，這只是通過訪問存儲庫和正式標題來給予他們認可。

Drew：這很好，因為在這種情況下，為開源項目做出貢獻可以真正回報個人。 他們得到了一些認可，這可能會對您的職業生涯以及您擁有的東西產生影響。

Drew：對於可能不習慣 Vue 但可能熟悉其他響應式框架的聽眾，例如您知道 React、Angular 等。 Vue 3 有哪些重大的標題變化，特別是它們試圖解決的問題是什麼？ 您之前提到構圖是其中之一，那是大的變化嗎？

Natalia：是的，這是最大的變化之一，它實際上是其中之一，首先，讓我在這裡明確聲明。 組合 API 純粹是附加的。 不是你需要重寫你的組件，你可以給它們添加 TypeScript。 或者您可能更喜歡使用所有語法，現在我們將其稱為選項 API，這些術語不會對您有所改變。 就像，當我們談論新的 API 時，這並不是一個重大變化。 我只想真正強調這一點，這真的很重要，因為當它第一次宣布 Composition API 時，那是一個糟糕的時刻。

Natalia：我認為我們並沒有很好地描述這些變化，而且我們讓標準構建看起來像是 Composition API。 這完全是我們的壞事，選項就像，也許我們會在未來的構建中棄用它，而不是在 Vue 3 中，很明顯。 如果人們有可能讀錯你說的話，他們就會讀錯。

Natalia：在這個聲明之後，我們剛剛在 RFC 中提出了改變，Reddit 爆炸了。 Reddit 上充滿了類似的東西，“哦，我的上帝。 我將需要寫下一切。 我的天啊。 Vue 是新的 Angular。 他們會破壞所有的東西。” 還有一個人在 dev.to 上寫了一篇文章，叫做 Vue's Darkest Day。 老實說，那是最黑暗的一天。 我們是這麼認為的，但我想在自己的 Twitter 上與此作鬥爭，比如，“我們不是真正的人……他們說我們開始改變 RFC，我認為 Evan 開始改變 RFC 卻沒有宣布改變。 所以他就像，“我會很快重寫這個。 讓我們像推入大師一樣”。 人們對此很生氣。 因為他們在爭論某些觀點，所以你只需刷新一個頁面，這些觀點就不再存在了。 你覺得，我是個傻瓜還是只是……什麼鬼？ 我的意思是，它就在那裡。 我記得這個。 而且我相信我們的溝通策略可以更好，這不是我們。

娜塔莉亞：現在，每次我談到作曲時，這純粹是加法，人們。 這只是一個不錯的功能。 你可以使用它，你不能使用它，你沒有義務這樣做。 只是……它存在。

Drew：如果Composition API 是一種新事物，可以幫助他們擺脫這個問題，那麼人們可能會遇到什麼樣的問題？ 它在解決什麼問題？

Natalia：想像一下內部有一些功能的組件。 假設它是搜索和排序。 假設我們搜索某個列表並嘗試對其進行排序。 這已經是兩個不同的特性，而 Vue 組件的特點是，它們是根據選項而不是邏輯進行拆分的。 想像一下，您的搜索可能有一個查詢，因為您需要對搜索和結果數組進行查詢。 這是兩個反應屬性。 就您的組件而言，您將它們放在稱為數據的選項中。 顯然你需要一些方法來執行排序。 也許是單擊按鈕，也許是其他東西，運行搜索的東西。 您創建方法。 對於排序，您需要在排序選項上構建一些東西，這是另一個反應性屬性。 然後你執行一些計算來對結果進行排序。

Natalia：在 Vue 中，為此，您還擁有計算屬性，這是另一種選擇。 最後，您的組件變得非常碎片化。 想像一下我是一名開發人員，我的任務是只在搜索部分工作。 我現在不能拆分組件，因為這兩個功能在它們的方式上有點交叉。 我搜索一些結果並對它們進行排序。 而且我需要從數據跳轉到方法，從方法跳轉到計算，最後真的很難切換上下文。 特別是如果組件變得非常大。

Natalia：我們在 Vue 2.0 中有哪些選擇？ 第一個選項稱為 mixins，mixin 只是一個對象，它可以包含組件可以具有的相同屬性，我們正在將它們與組件混合。 聽起來不錯，我可以將所有搜索移到那裡，有什麼問題？ 有幾個。 首先，這完全不靈活。 如果我想搜索某個端點並將其移動到 mixin，這將是我可以搜索的唯一端點。 Mixin 不接受參數。 我創建了一個 mixin，它完全是靜態的。 第二個問題是混入了 mixin，這意味著對於某些屬性，它就像合併一樣發生。 例如，如果您創建了鉤子，它將被合併。 來自 mixin 組件的生命週期鉤子中的所有邏輯都合併在一起。 但是，如果您有一個數據屬性，mixin 中有一個冷查詢，並且您有任何機會在組件中具有相同的屬性，則該組件具有優先級。 它將被覆蓋。 您不會收到任何警告。 絕對地。 它會發生，你不會知道這會發生。

德魯：所有的範圍都是完全混合的？

娜塔莉亞：是的，完全。 你沒有機會看到，而且，mixin 的來源非常不清楚。 您只需導入帶有名稱的mixin並將其放入查看組件屬性mixin，就是這樣。 這是非常含蓄的，我是從我自己的經驗來看的。 我們在 GitLab 中有一個邏輯，其中一個組件包含兩個 mixin，而這兩個 mixin 中的每一個都包含另一個 mixin。 到這裡，這是您需要檢查的屬性，它不在組件中。 讓我們更深入，第一級混合。 這個不包含它，這個也不包含它。 在哪兒？ 您正在深入研究，就在兔子洞的深處，只是為了找到這個屬性，測試也變成了一場噩夢。

Natalia：讓我說，Mixins 是一種非常愚蠢的提取邏輯的方法。 很簡單，很清楚，很容易得到。 如果您想在高級級別上使用它，它會給您帶來很多問題。 Vue 2.0 中抽象邏輯的下一個方法是無渲染組件。 在 Vue 中，組件可以包含一個插槽。 基本上，您可以在其中放置父組件中的任何內容。 一個小窗口，實際上是一個插槽。 並且有一個範圍插槽的想法。 想像一下子組件可以將自己的作用域暴露給父組件，並且插槽內容將可以訪問它。 想像一下，我有一個帶有插槽的組件，組件執行有關搜索的所有邏輯，假設搜索的終點​​是過去的參數。 我們的子組件，例如搜索，然後將其範圍的這一部分公開給父組件。 這些是搜索結果。 享受。 聽起來不錯。 聽起來絕對比 mixins 好。 我們可以測試參數。 這裡的邏輯很明確，我們正在返回一些東西。 問題？ 有幾個。

Natalia：首先，您已經創建了組件實例。 這不是世界上最便宜的手術。 第二部分，運行時。 該組件僅在運行時有效，這意味著該組件的公開屬性只能在您將其公開為插槽範圍的插槽中，因此您的搜索結果僅在模板的一小部分中可用。 如果您想使用組件的離散部分，則無權訪問那裡。 它是運行時。 如果您在其他地方需要反應狀態，則無需執行此邏輯。 當然它可以像純函數一樣創建助手並返回結果，但是，如果我需要對反應屬性進行操作怎麼辦？ 這就是組合 API 的創建方式。 使用 Composition API，您可以擁有獨立的反應狀態。 反應狀態不再只是組件的一部分。 您可以使任何對像或原語具有反應性。 你可以把它暴露給父母，這是非常明確的。

Natalia：你想歸還給父母的每一個財產都暴露了。 很明確，你可以點擊這個，你可以看到它在哪裡，它是什麼，等等。 最好的部分是，如果您將 Composition API 的部分包含到具有數據方法、計算機屬性等的舊組件中，它就可以正常工作。 它工作得很好，您只需向組件添加一些反應性屬性和方法，您也可以將它們與舊選項 API 一起使用。

Drew：當涉及到非常複雜的組件甚至是輕度複雜的組件組合時，這聽起來真的會幫助開發人員清理他們的代碼庫。 你提到了 mixins 和事物的可測試性，Composition API 是否允許更好的可測試性？

Natalia：是的，絕對是因為 Composition API，如果我們從中排除生命週期鉤子，因為您還可以在 composeable 中運行另一個生命週期鉤子。 它實際上是純函數。 你有 S 參數，你正在做某事並且在生命週期鉤子之外仍然有副作用。 如您所知，測試純函數可能是最簡單的事情。 它只是一個黑匣子，你有 S 參數，你有東西要返回。

Drew：這聽起來是一個非常全面的解決方案，我相信很多使用 Vue 構建更複雜應用程序的人都會喜歡它。 這聽起來確實是一種非常好的方法來消除我知道可以通過 mixins 潛入的那種錯誤，其中很容易引入錯誤，就像你提到的那樣，合併範圍和所有這些事情。

Drew：我一直認為，在選擇在框架之上構建時，一個重要的考慮因素是它的 API 隨著時間的推移的穩定性。 也許穩定性不是一個正確的詞，但我認為我們中的許多人已經被構建在一個框架之上，然後經歷了一次大的改造，並給我們留下了需要大量投資才能遷移的應用程序，或者它們最終被綁定到不再支持的舊版本的框架。 這是一個可怕的情況。將一個大項目從 Vue 2 遷移到 Vue 3，我會失去多少睡眠？

Natalia：首先，API 表面與原來的 90% 相同。 我們沒有那麼多可被棄用的事件中心替換的棄用的東西或棄用的過濾器。 如果您想使用 EventEmitter，您還需要將基於視圖的視圖替換為一些外部庫。 這些都是很大的變化，但說到遷移……讓我說清楚，我現在真的很傷心，因為一方面我是 Vue JS 核心團隊的成員。 另一方面，我是使用 Vue 的大項目中的一名高級工程師。 如果您現在要開始遷移，我不建議您這樣做。 首先，生態系統沒有發布，我的意思是，如果我們談論 Pure Router、PUX、Vue CLI 等核心庫，這些庫的狀態很好，但它們仍然是候選發布版，而不是發布版。 如果我們談論其他生態系統，比如可能不是核心庫、UI 組件庫，可能是一些表單驗證庫，它們大多還沒有為 Vue 3 做好準備。如果你有一個大項目，你需要有很多依賴項關心。 所以這將是一件複雜的事情。

娜塔莉亞：有什麼選擇？ 你有一個大項目，你想使用所有這些 Composition API 的優點。 如何做到這一點？ 首先，我們計劃發布 Vue 2.0、Vue 2.7 的 LTS 版本。 這將包括大量棄用警告，因此您將能夠看到將要棄用的內容，以及如何重構它以不使用 Vue 3 破壞它。所以從技術上講，您仍將使用 Vue 2，但您將準備 Vue 3無論如何，因為你有所有的警告。

Natalia：其次，我們將使用一個能夠運行它的遷移工具，它將作為一個 codemod 工作，用 Vue 3 替代品替換與 Vue 2 相關的東西。 當然，沒有代碼模塊是完美的。 首先，我們的目標是盡可能進行替換，但在不容易處理棄用時也會顯示警告。 Codemod 將能夠識別事物並發出警告，但不能自行替換它。 這就像一個大計劃，當 Vue 2.7 發佈時，如果我沒記錯的話，我認為現在他們的估計時間是 12 月，我需要查看路線圖，但我認為是 12 月。

Natalia：生態系統也將或多或少準備就緒。 如果您有一個使用 Vue 2.0 的大型項目，請稍等一下，直到 Core 穩定下來，因為即使您製作了一個完美的庫，它仍然需要一些時間來穩定，因為人們開始使用它，人們開始報告錯誤。 如果您打算將它用於寵物項目並報告錯誤，請非常歡迎您這樣做。 在此之後將有一個很好的平滑方式遷移到 Vue 3。

Drew：所以你提到的遷移工具聽起來很有趣。 這基本上是一個靜態分析工具，可以查看您的代碼並......

Natalia：是的，是的，是的，它是一個代碼或一個工具。 現在它以非常有限的方式可用。 它可以作為 Vue CLI 的插件使用。 如果您有基於 Vue CLI 的項目，您可以運行 Vue 升級並查看該工具的工作原理。 到目前為止，它還不是我們想要的形狀。 不幸的是，我不從事基於 Vue CLI 構建的項目。 我需要等待並檢查發生了什麼，但是，例如 GitHub，即使沒有準備遷移工具，我們也已經採取了一些步驟，因為我們知道不推薦使用的內容。 它實際上在 Vue 3 文檔中有所說明。

Natalia：有遷移指南。 您可以看到所有重大更改和已棄用的內容，甚至可以在 Vue 2.0 代碼庫上處理其中的一部分。 例如，在 Vue 2.6 中，我們更改了插槽的語法。 範圍槽的語法已被棄用但未被拒絕，它仍然存在。 它會發出警告，但您可以運行它。 當然，對於一個已經有 7 年曆史的代碼庫，沒有人會關心替換所有已棄用的語法，如果它正常工作的話。 生產中沒有警告。 插槽工作。 在開發中，“哦，我在控制台中看到了一些警告。 可能有20個，很好。 是黃色不是紅色。 我不在乎”。

娜塔莉亞：你知道這發生在每個人身上。 我們創造了一個巨大的史詩來解決這個問題。 查找所有當前的舊語法集。 我們努力替換我們的 EventEmitters，同樣，七年的項目，不要評判我們。 我們有 EventEmitters。 GitLab 正在開發 EventHubs。 我們用外部庫替換了基於 Vue 的樂趣。 我建議也這樣做。 通過遷移指南檢查已經可以替換的內容以及您已經可以進行哪些更改以準備並開始工作。

Drew：在遷移工具的當前狀態下，這是一個用代碼庫測試水域的好方法。 只是運行它，看看它已經標記了什麼，看看它是否看起來還可以，或者是否有一些大的東西，或者它是否仍然不成熟？ 等到 12 月才能真正解決問題會更好嗎？

Natalia：如果我有一個大項目，我不建議這樣做。 如果您有一個小的壞項目或者一些個人項目，但它不是那麼大，我建議您運行它並檢查您擁有的任何問題，因為對於兩個中型項目，我一直在運行它。 我想一兩個問題。 我不能說它不成熟。 它已經處於良好狀態。 但是對於大型項目來說，它是遺產，是一些異國情調的東西。 不要在生產中這樣做，人們。

Natalia：另外，如果您想使用項目的腳手架，現在 Vue CLI 支持兩種模式。 您可以創建 Vue 2 項目，也可以創建 Vue 3 項目。 至少一定要試一試。 這對我們來說也是一個好方法，因為當您玩遊戲時，您會發現錯誤，報告錯誤，我們會嘗試修復它們等等。

Drew：在文檔和開發路線圖中，我看到提到了遷移構建。 這與我們談論的內容不同還是我們正在談論的內容不同？

娜塔莉亞：不，不，都是一樣的。 它是同一個，它應該已經準備好了，但是現在，如果您計劃遷移，主要路徑就是閱讀文檔並遵循那裡所說的任何內容，因為只要我們沒有遷移工具，我們肯定會努力，文檔團隊繼續前進並創建了詳細指南，說明了更改內容、進行更改的原因以及此處實際替換的內容。

Drew：是的，作為 Vue 3 文檔的一部分，文檔中有一個非常全面的遷移指南，其中提到了需要遷移的大量更改。 我想其中一些不會影響每個項目。 對於很多人來說，其中很多基本上都是邊緣案例。 這公平嗎？

Natalia：是的，其中很大一部分，例如過濾器，肯定是一些邊緣案例，因為即使在 GitLab，第三次使用七年的代碼庫和一個大代碼庫。 我們有一兩次過濾器出現，它們不再使用了。 我們搜索並完全刪除它們是一件好事，因為就像“哦，未使用的代碼”，再說一次，誰在乎它只是存在。

Natalia：我會說完全顛覆性的變化是模型的變化。 看看這個，因為我知道的每個項目都至少包含一個 Vue 模型，這是肯定的。 這應該被檢查，也許屬性也會改變，因為目前我們包括類和風格，管狀和以太。 如果你曾經使用過 Vue，以前它不包括在內。 現在，將類和样式傳遞給子組件的方式略有不同，它們絕對值得關注。

德魯：很高興知道。 與 Vue 一起發布的 3.0 版本，我的意思是你提到了生態系統和它周圍的一切，Vuex 和生態系統的所有其他部分，需要推進到那個水平。 這就是為什麼，目前，網站、“開始”這個大按鈕仍然全部使用 Vue 2 嗎？ 感覺就像 Vue 3 已經發布但沒有完全的信心。 但是否因為生態系統問題，它仍然如此？

Natalia：不，我想你只是發現了一個錯誤，讓我快速檢查一下。 不，get started指向Vue 3，沒問題。 我的意思是，如果您訪問 vuejs.org，它會指向第二版。 這是有意的，因為我們計劃用 Vue 2 之類的子域替換它，該子域正在進行中，但到目前為止，我們決定將 vuejs.org 留在原處並創建 Vue 3，這就是為什麼在 vuejs 上有一個橫幅。組織。 如果你去看任何文檔-

德魯：是的，頂部有一個非常小的橫幅。

娜塔莉亞：是的，就像小號一樣。

德魯：是的。

娜塔莉亞：我想我們應該把它弄大點。 更大並且具有更好的色彩對比。 我的可訪問性感覺就像，“哦，那裡沒有對比”。

德魯：這是個好消息。 如果有人開始，也許不是一個大項目，但如果有人開始個人項目或想學習 Vue，當然，Vue 3 是開始的地方嗎？

娜塔莉亞：我會這麼說。 順便說一句，學習曲線並沒有那麼不同。 因為文檔團隊打算使用舊的語法選項，所以我不應該說舊的，它實際上是當前的語法。 熟悉的語法作為默認語法。 因為如果您瀏覽 Vue 3 文檔，您只會在高級主題中看到 Composition API，並且您使用 Vue 3 的學習路徑與您在 Vue 2 中的學習路徑有點相似。從較新的開始沒什麼大不了的如果你只是學習 Vue 並嘗試使用它，我相信如果我們談論職業，這將是一個更好的投資。 開始學習新版本，因為它會超過所有項目。 最終，可能半年，一年，即使是大型項目也會有遷移。

Drew：在我的個人職業生涯中，我似乎擁有進入平台的真正才能，就像他們正處於大遷移的過程中一樣。 我的意思是，你還記得嗎？ 當他們正在過渡到點語法時，我想到了這一點，我必須同時學習兩者。 我在這裡，我發現自己在上個月第一次在 Vue 中工作，這是一個 Vue 2 項目，我邊走邊學習，並期待 Vue 3 中的所有內容。當然，在遷移過程中學習一些東西是一個有趣的時間，但聽起來 Vue 並不太難，一旦生態系統趕上了 Core，那麼我們應該處於一個好位置。

娜塔莉亞：哦，德魯，我只是想說明一下你所說的關於大項目移民的一切。 你可以想像我，2018 年，我加入了 GitLab。 我不是核心團隊的成員，我只是此刻的貢獻者。

Natalia：就在 Evan 說“哦，我們要製作 Vue 3”的同時。 每個人都喜歡，“是的，很酷”。 2019 年春天，您是核心團隊。 我的意思是整個 GitLab 就像，“哦，這很可愛。 我們都有移民，你知道誰應該對此負責嗎？” 你只能想像當你為 Vue 3 編寫文檔時會發生什麼，每個人都會閱讀，而你自己的公司會說，“哦，我想了解一些關於 Vue 3 的知識，我看不懂你的文檔。” 所以你會說，“哦，該死的，這太痛苦了”，因為你是那裡的開發人員和技術作家，有點在這裡。

Natalia：你在這中間，但是，我不得不說它對框架也非常有益，因為任何用框架創建的大產品都是一個偉大的、絕對偉大的戰場，可以找到錯誤並將它們帶回庫，以生態系統。 可以說是測試，而且 GitLab 是開源的，Vue Test Utils，是 Vue 的一個測試工具。 一個團隊正在使用我們基於測試的測試代碼，這很有意義，對。 因為你可以找到一些邊緣情況等等。 但是，當我考慮將 GitLab 遷移到 Vue 3 時，我覺得自己對此負有責任。 我不僅在遷移中，而且我個人對我們將發現的每一個錯誤負責。

Drew：回顧上一代的 JavaScript 框架，我認為其中最成功的框架之一是 jQuery，在當時，我認為它之所以受到關注，是因為它有一個設計得非常好的 API。 正是這種使用 CSS 選擇器並使用它來查詢 JavaScript 中的 DOM 的概念是 jQuery 普及的東西。 And I think that really resonated with hardworking developers who didn't need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it's doing. And if I need to do something I've not done before I can sort of guess at how it would be implemented and usually I'm right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It's changed slightly but we had a concept that was called Documentation Driven Design. And it's a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that's why it's intuitive. If it's easy to explain, people probably will get it on themselves. That's why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don't need to explain what v-if is doing because it's clear, right.

德魯：確實如此。

Natalia: It's kind of insulting and same with v-else. V-if, v-else-if, v-else and that's it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It's all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn't work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It's so nice to use”. I'm just building the same stuff and it's just been a pleasure. I don't need to think about the tool, I'm thinking about what I'm going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I've been working with Angular from version two to version six on a commercial project and it's a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it's just hard being a developer. And after this, working with Vue is like, “Oh, it's just like a walk in the park”.

Drew: There can be a danger with software that when it's so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that's a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it's better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I'd been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it's easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You're free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it's not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I'm like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it's good and stable and it's developing and it's not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it's actually better for the framework.

Natalia: Last year we introduced the RFC process. It's actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it's not decided, it's not set in stone. We just have an idea and we want to hear what community thinks. I believe it's great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it's true. It's actually shaped by community. It's not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They're not shaping the framework and I believe this is great.

Drew: It's quite telling when you mentioned the list of active Core Team members is 20ish people and they're all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you're at GitLab and there are other people who are just independent consultants and it's not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We're changing direction, we're not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I've spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you're listening to this, the site will have changed and will just be Vue, but that's also where you find the docs and in the docs is that really good migration guide that we mentioned. I've been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I've been learning about Apollo Client version three. It's funny, because if you look at versions and I've been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we're adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you're curious about Apollo Client version three definitely give it a try. It's interesting to see how it's evolving.

Drew: I'm definitely going to give that a try. I've used Apollo on a couple of projects and it's really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.