前端相關
【Vue】【Rect】生態圈相關名詞
以下是 Vue 與 React 生態圈的比較表，幫助你快速了解兩者的主要工具和技術差異：
| 類別 | Vue 生態圈 | React 生態圈 |
|---|---|---|
| 核心框架 | Vue.js（漸進式前端框架） | React（Meta 開發的 UI 庫） |
| 進階框架（SSR / SSG） | Nuxt.js（支援 SSR、SSG、SPA） | Next.js（支援 SSR、SSG、API Routes） |
| Remix（更強調伺服器端渲染） | ||
| 狀態管理 | Vuex（官方舊方案，已被取代） | Redux / Redux Toolkit（最流行，但繁瑣） |
| Pinia（官方推薦，比 Vuex 簡單） | Recoil（Facebook 開發，簡單高效） | |
| Vue Composition API（內建狀態管理） | Zustand（輕量簡單，替代 Redux） | |
| Vue Query（類似 React Query） | React Query（最佳 API 資料管理） | |
| 路由管理 | Vue Router（官方路由） | React Router（官方路由，適合 SPA） |
| UI 框架 | Vuetify（Material Design） | Material UI（MUI，Google Material Design） |
| Element Plus（適合後台） | Ant Design（企業級 UI 框架） | |
| Quasar（跨平台支援） | Chakra UI（彈性設計，易用） | |
| Tailwind CSS（支援 Vue） | Tailwind CSS（最流行的 CSS 框架） | |
| HTTP 請求 & API 管理 | Axios（最常用的 HTTP 客戶端） | Axios（最常用） |
| Vue Query（類似 React Query） | SWR（Next.js 推薦，輕量 API 快取） | |
| 動畫 & 特效 | Vue Transition（內建動畫） | Framer Motion（最流行的動畫庫） |
| GSAP（強大的動畫庫） | GSAP（適合複雜動畫） | |
| 開發工具 | Vite（Vue 3 預設建構工具） | Vite（React 也推薦使用） |
| Vue CLI（Vue 2 舊版建構工具） | Create React App（CRA，舊版 React 專案用） | |
| Vue DevTools（瀏覽器開發工具） | React DevTools（官方瀏覽器工具） | |
| 測試工具 | Vitest（Vue 3 單元測試） | Jest（最常用的 React 測試框架） |
| Vue Testing Library（測試 Vue 組件） | React Testing Library（測試 React 組件） | |
| Cypress（E2E 測試） | Cypress（E2E 測試） | |
| 部署 & 靜態網站 | VuePress（靜態網站生成） | Gatsby（React 靜態網站框架） |
| Nuxt Content（Markdown 內容管理） | Docusaurus（React 文件網站） | |
| Vercel / Netlify（雲端部署） | Vercel / Netlify（雲端部署） | |
| 新技術 & 特性 | Composition API（Vue 3 核心變革） | React Concurrent Mode（提升渲染效能） |
| Teleport（將組件渲染到指定 DOM） | React Server Components（適用於 Next.js） | |
| Suspense（處理異步請求） | Suspense（類似概念，處理異步） | |
| 架構模式 | CSR（傳統 SPA，SEO 較差） | CSR（傳統 React SPA） |
| SSR（Nuxt.js 提供） | SSR（Next.js / Remix 提供） | |
| SSG（Nuxt 也支援） | SSG（Next.js / Gatsby 支援） |
🔹 總結：
- Vue 適合 簡單上手、開發體驗佳 的專案，Nuxt.js 是 SSR / SSG 的最佳選擇。
- React 擁有 更大的生態圈，Next.js 和 Remix 提供 更強的伺服器端能力，適合大型應用。
- Vue 適合小型 / 中型專案，React 更適合大規模應用。
如果你對某個領域（如 SSR、狀態管理、測試）想進一步了解，歡迎問我！🔥
【名詞解釋】【JS】Tree-Shaking (搖樹優化)
Tree-Shaking (搖樹優化) 是一種在前端開發中非常重要的程式碼優化技術，它主要用於 JavaScript 模組。它的核心思想是消除那些最終應用程式中沒有使用的程式碼，從而減少打包後的檔案大小，提升網頁加載速度和執行效率。
什麼是 Tree-Shaking？
你可以把 Tree-Shaking 想像成一棵程式碼樹。你的專案代碼就是這棵樹的主幹和分枝，而你從各個模組中引入的函式、變數等，就是這棵樹上的葉子。
Tree-Shaking 的目的就是「搖掉」那些從未被使用的「葉子」。
在傳統的 JavaScript 模組中，即使你只引入了一個庫中的一個函式，整個庫的程式碼也可能會被打包進來。但有了 Tree-Shaking，打包工具能夠分析你的程式碼，識別出哪些部分實際被使用了（被「引用」或「匯入」），哪些部分從未被使用。最終，那些未被使用的程式碼就會在打包時被移除，就像秋天樹葉被搖落一樣。
Tree-Shaking 的運作原理
Tree-Shaking 的實現依賴於 ES Modules (ESM) 的靜態分析特性。
-
靜態分析 (Static Analysis)：
ES Modules (使用 import 和 export 語法) 允許打包工具在編譯時期（而不是執行時期）分析模組之間的依賴關係。這意味著打包工具能夠清楚地知道每個模組輸出了什麼，以及你的程式碼從其他模組導入了什麼。
-
標記 (Marking)：
打包工具（例如 Webpack、Rollup）會從你的應用程式的入口點開始，追蹤所有 import 和 export 語句。它會遍歷所有的程式碼，將實際被使用到的程式碼片段標記為「已使用」(used)。
-
清除 (Sweeping)：
在標記完成後，打包工具會將所有未被標記為「已使用」的程式碼片段從最終的打包檔案中移除。這些未被使用的程式碼被視為「死程式碼」(dead code)。
重點： Tree-Shaking 只有在你的程式碼是 ES Modules 語法時才能有效運作。這是因為 CommonJS (使用 require 和 module.exports) 等其他模組系統是動態載入的，打包工具難以在編譯時確定哪些程式碼會被使用。
誰在做 Tree-Shaking？
Tree-Shaking 主要由現代化的模組打包工具 (Module Bundlers) 來實現，其中最著名的就是：
-
Webpack (版本 2 及以上)：Webpack 預設支援 Tree-Shaking，但在實際使用中，為了達到最佳效果，你可能還需要做一些配置，例如啟用
optimization.usedExports和確保你的 Babel 配置不會將 ES Modules 轉換為 CommonJS。 -
Rollup：Rollup 在設計之初就強調了 Tree-Shaking 的能力，它通常被認為在庫的打包方面效果更好，因為它能生成更小、更扁平的程式碼。
-
Vite：Vite 在開發模式下利用瀏覽器的 ESM 原生支援，在生產環境則使用 Rollup 進行打包，因此也具備出色的 Tree-Shaking 能力。
Tree-Shaking 的好處
-
更小的檔案大小： 這是最直接的好處，程式碼量減少，下載所需時間也減少。
-
更快的加載速度： 瀏覽器需要下載和解析的 JavaScript 檔案更小，網頁加載速度自然更快。
-
更低的執行成本： 瀏覽器需要執行的程式碼更少，降低了 CPU 和記憶體的使用。
-
更好的使用者體驗： 網站響應更快，用戶體驗更流暢。
實際應用中的注意事項
為了確保 Tree-Shaking 能夠發揮最大效果，你需要注意以下幾點：
-
使用 ES Modules 語法： 確保你的專案程式碼和引用的第三方庫都使用
import和export語法。 -
配置 Babel (或 TypeScript)： 如果你使用 Babel 或 TypeScript 轉換程式碼，請確保它們不會將 ES Modules 轉換為 CommonJS 模組，否則打包工具將無法進行靜態分析。在 Babel 中，這通常意味著將
@babel/preset-env中的modules選項設定為false。 -
確認第三方庫是否支援 Tree-Shaking： 有些第三方庫可能沒有設計成 Tree-Shaking 友好的形式。理想情況下，庫會在其
package.json中設定sideEffects: false，表明其程式碼沒有副作用，可以安全地進行 Tree-Shaking。 -
避免副作用 (Side Effects)： 包含副作用的程式碼可能會阻止 Tree-Shaking。例如，直接在模組的頂層執行一個函式可能會被打包工具視為副作用，即使這個函式本身沒有被顯式引用，也可能不會被移除。
總之，Tree-Shaking 是一種利用 ES Modules 靜態分析特性，移除未使用的程式碼，從而優化前端應用程式效能的關鍵技術。理解並正確配置它，對於構建高效能的網頁應用程式至關重要。
【轉載】什麼是 Virtual DOM？從底層原理到 React 的渲染策略
出處：https://hackmd.io/xejlCpUsQaibO90CYB5CJg
為什麼要談 Virtual DOM？
每當我們在網頁上看到動態更新的內容，背後都可能涉及了對 DOM (文件物件模型) 的操作。然而，DOM 與瀏覽器的渲染引擎是緊密耦合的，任何一次看似微小的改動，都可能觸發瀏覽器進行成本高昂的 重排 (Reflow) 與 重繪 (Repaint)，頻繁的操作最終會成為應用的效能瓶頸。
為了在提供豐富互動的同時，又能維持流暢的體驗，前端框架必須找到一個方法來「最小化對真實 DOM 的操作」。而 Virtual DOM，正是為此而生的一種優雅策略。
DOM 是什麼？為什麼慢？
很間單的先用一句話說明是：瀏覽器呈現 UI 的載體。但在我整理資料之後我覺得可以用更精細的說明：
- 網頁瀏覽器內部的 HTML 解析器(parsing)會將原始的 HTML/XML 文本解析並轉換為一個樹狀的資料結構，這就是 Document Object Model (DOM)。
- DOM 的每個節點都代表文件中的一部分，並以 JavaScript 物件的形式存在，提供了一系列屬性與方法 (DOM API)。
- JavaScript 正是透過這些 DOM API 來存取、查詢、修改這些節點，從而動態地控制網頁的內容、樣式和行為，實現使用者互動。
麼是 Reflow / Repaint？
- 回流 (Reflow)：當 DOM 元素的幾何屬性（如寬度、高度、位置）發生改變，導致瀏覽器需要重新計算元素在頁面上的佈局時，就會觸發回流。
- 重繪 (Repaint)：當元素的外觀屬性（如顏色、背景）發生改變，但不影響其佈局時，瀏覽器只需重新繪製該部分的外觀，這個過程稱為重繪。
- 回流必定會觸發重繪，但重繪不一定會觸發回流。因此，回流對效能的影響遠大於重繪。
每次 DOM 變化都可能觸發效能瓶頸
瀏覽器在操作 DOM 的過程中都有可能引發 Reflow 或 Repaint，過程中是仰賴 瀏覽器CPU 需要重新計算，在反覆的過程中是可能引起效能瓶頸的。
其餘內容請看原站～～