去年,我從 Vue 3.6 的 Composition API 開始,重新理解 Vue 的設計。今年想繼續往下追:Vue 升級後,到底真的改善了什麼?
這次從過去實戰中遇到的痛點出發,跟 AI 一起做實驗、跑不同情境、看數據,找出 Framework 與 Architecture 各自該負責什麼。
我們很清楚 Vibe Coding 勢在必行。只是當 AI 能幫我們完成需求、產生更多 Code,我們是不是更需要知道:什麼該交給 AI?什麼該交給 Framework?什麼事情還是需要自己判斷?
這就是今年這 30 天想一起聊的事情。
拆組件的原則是什麼?要拆多細? 前一個階段,我們花了幾天處理 Reactive Chain Hell,得到一個很明確的結果 Vue 可以改善 Runtime...
把「Component 越多是否帶來 Runtime Cost」轉成一個固定的 Mount / Update 實驗 上一篇,我們完成了第一個假設 React...
500 個 Component 都在頁面上,但資料改變時,它們真的都需要一起工作嗎? 如果說 Reactive Chain 看的是資料怎麼傳,那 Compo...
如果換成 Vue 3.6,昨天看到的這些成本,真的會消失嗎? 昨天用 Vue 3.5.40 建立了 Component Storm 的 baseline,在...
Framework 可以降低單次成本,但 Architecture 決定一次更新要處理多少範圍 Day 14 的 Component Storm 實驗,讓問...
你相信嗎?大量 UI 本身,就可能成為 Runtime Cost 前幾天,我們一直在追 資料發生變化之後,Vue 到底需要做多少工作? Reactive C...
大量 UI Rendering 時,Vue Runtime 的成本在哪裡?新版 Runtime 是否真的改善? 商品列表、Dashboard、CRM、管理後...
先建立 Vue 3.5 Baseline,再談 Vue 3.6 是否真的改善 昨天建立了 VDOM Stress Test,同一個 Scenario,分別測...
從 Render Duration 到 Framework Attribution,如何判斷效能改善來自哪一層? Day 18 做完 VDOM Stress...
那既然 Framework Improvement 沒有被確認,目前真正存在的成本結構是什麼? Day 19 比較了 Vue 3.5.40 與 Vue 3....