首先對(duì) Vue 團(tuán)隊(duì) Respect，大佬們辛苦了！開發(fā)除了這么優(yōu)秀的前端工具庫(kù)！

以下僅代表個(gè)人觀點(diǎn)~我知道沒人會(huì)在乎一個(gè)菜鳥到底用不用 Vue3.5 ，我只是發(fā)表了我的個(gè)人看法，這并不代表我不尊重 Vue，我超愛 Vue 的?。。?/p>

其實(shí)早在 VueConf 2024 上，尤大就公布了Vue3.5的新特性，并且說明了目前該版本還在開發(fā)中，正處于 alpha 階段。

圖片

我調(diào)研了我們組的前端同事們，以及結(jié)合我個(gè)人的想法，我是覺得：我應(yīng)該會(huì)跳過 Vue3.5 這個(gè)版本。

說 3.5 之前，先回顧一下 3.4

在說 Vue3.5 之前，我想先先回顧一下 Vue3.4這個(gè)版本，因?yàn)槲覍?shí)在覺得 Vue3.4 太棒啦?。?！

以下是 Vue3.4 的特性：

1、徹底重構(gòu) parser，加快一倍

2、SFC 編譯 source map 優(yōu)化，提速可達(dá) 50%

3、響應(yīng)式系統(tǒng)重構(gòu)，更精確的 computed 計(jì)算觸發(fā)

4、defineModel 成為穩(wěn)定功能

5、v-bind 語法糖

除了 5、v-bind 語法糖 這一點(diǎn)我個(gè)人覺得對(duì)我沒啥用處以外，其他幾點(diǎn) 簡(jiǎn)直太棒了?。?！

• parser 重構(gòu)、SFC 編譯 source map 優(yōu)化： 這都是實(shí)打?qū)嵉靥嵘司幾g速度啊！編譯速度直接影響了開發(fā)體驗(yàn)！簡(jiǎn)直太棒了??！
• 響應(yīng)式系統(tǒng)重構(gòu)： 我還記得以前watchEffect這個(gè) API 無論依賴改變前后相不相同，都會(huì)觸發(fā)watchEffect回調(diào)重新執(zhí)行（性能問題），而響應(yīng)式系統(tǒng)重構(gòu)是徹底解決了這個(gè)性能問題！簡(jiǎn)直太棒了！！
• defineModel： 以前封裝組件時(shí)涉及到父子數(shù)據(jù)雙向綁定時(shí)，都很麻煩，而有了defineModel 之后，瞬間簡(jiǎn)單了！簡(jiǎn)直太棒了??！

反觀 Vue3.5

說完Vue3.4，我們來反觀一下Vue3.5，我來說說為啥 我應(yīng)該會(huì)跳過 Vue3.5 這個(gè)版本。

Props 響應(yīng)式解構(gòu)

以前 Props 解構(gòu)后就會(huì)丟失響應(yīng)式，但是 Vue3.5 支持 Props 響應(yīng)式解構(gòu)了。

圖片

雖然我知道這個(gè)新特性挺實(shí)用的，但是我覺得對(duì)于我來說，好像用處不大，反而會(huì)對(duì)我的開發(fā)造成阻力，我始終覺得：props 還是不要解構(gòu)的好。

請(qǐng)看下面例子，我如果不解構(gòu)，每個(gè)地方都用 props.count，那么我會(huì)很清楚 count 這個(gè)變量的數(shù)據(jù)是來源于 props，當(dāng)組件內(nèi)代碼太多的時(shí)候，這些代碼被擠到下面的時(shí)候，我還是能很清楚地分清 count 和 total 兩個(gè)變量數(shù)據(jù)來源的區(qū)別，前者是傳進(jìn)來的，后者是本組件自己的。

圖片

但是如果你進(jìn)行 Props 解構(gòu)的話，那就是下面的場(chǎng)景，當(dāng)本組件代碼很多的時(shí)候，而導(dǎo)致你看不到變量定義代碼時(shí)，請(qǐng)問你怎么區(qū)分 count 和 total 兩個(gè)變量數(shù)據(jù)來源？

圖片

useTemplateRef

以前無論是響應(yīng)式變量還是 組件實(shí)例獲取 ，都是使用 ref 去定義，可能會(huì)造成代碼視覺上的混淆。

圖片

所以 Vue3.5 推出了 useTemplateRef 來進(jìn)行 組件實(shí)例獲取，從而跟 響應(yīng)式變量 區(qū)分開。

圖片

但是其實(shí)就算沒有 useTemplateRef，使用過Typescript的朋友都知道，當(dāng)響應(yīng)式變量 和 組件實(shí)例獲取 都使用 ref 時(shí)，完全可以憑借 Typescript 去區(qū)分。

圖片

就算你不習(xí)慣Typescript吧，但是 useTemplateRef 也未必就適用于 組件實(shí)例獲取 的所有場(chǎng)景，比如 多組件實(shí)例獲取，這個(gè)時(shí)候你還是得用回 ref 啊。。

圖片

useId

就是在組件內(nèi)生成一個(gè)唯一的 ID，以便于在做一些邏輯時(shí)，與其他組件隔絕開來。

圖片

但是其實(shí)不太需要 useId，因?yàn)檫@種隔絕方式，很久很久以前就在用了，反正我自己的話使用的是 lodash 的 uniqueId。

圖片

內(nèi)存優(yōu)化 + 大數(shù)組優(yōu)化

尤大說了，Vue3.5 中重構(gòu)了響應(yīng)式系統(tǒng)。使得**內(nèi)存占用率減少了 60%**，牛?。。。。∵@一點(diǎn)確實(shí)是非常的好?。。?！

尤大還說到，Vue3.5 重構(gòu)了很多數(shù)組方法，這讓大數(shù)組遍歷操作的雙速度提升了 10 倍。但是我覺得這個(gè)提升只是僅限于邏輯處理層面，但是 DOM 渲染該渲染慢還是那么慢。

比如在 Vue3.5中，一個(gè)數(shù)組有 10w 條數(shù)據(jù)，并在頁面上遍歷渲染出 10w 個(gè)DOM節(jié)點(diǎn)，當(dāng)你對(duì)這個(gè)數(shù)組進(jìn)行操作時(shí)，速度比過往提升了 10 倍，但是頁面上的 10w 個(gè)DOM節(jié)點(diǎn)的重渲染該卡還是卡啊。。。

除非這些數(shù)組方法速度的提升，能帶動(dòng) DOM節(jié)點(diǎn)重渲染數(shù)的減少，不然僅僅在邏輯處理層面提升，貌似整體也提升不了很多，就比如下面代碼，模擬了 100w 個(gè)數(shù)據(jù)的處理。

圖片

其實(shí)也就耗時(shí)了 1.19s 而已（JavaScript 并沒有你想象中那么慢），提升 10 倍，也就是 0.1s。

圖片

耗時(shí)的大頭其實(shí)是在 DOM 渲染上，如果 DOM 渲染速度也能跟著提升 10 倍，那就真的無敵了！??！

作為一個(gè) Vue 開發(fā)者，我所期待的

其實(shí)很簡(jiǎn)單，就是期望開發(fā)起來更加方便，所以 Vue Macros 里的很多超前 API 我都很期待，不知道 Vue Macros 是啥的請(qǐng)看這里：Vue3 超前版發(fā)布三個(gè)新特性！有望全面擁抱 JSX/TSX！

Vue Macros官網(wǎng)：https://vue-macros.dev/zh-CN/

圖片

小結(jié)

• Vue3.4 真的很棒?。?！
• 我很可能會(huì)跳過 Vue3.5 這個(gè)版本，因?yàn)閷?duì)我來說好像沒啥太大的飛躍。

以上僅代表個(gè)人觀點(diǎn)~我知道沒人會(huì)在乎一個(gè)菜鳥到底用不用 Vue3.5 ，我只是發(fā)表了我的個(gè)人看法，這并不代表我不尊重 Vue，我超愛 Vue 的?。?！