前端相關

【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 需要重新計算，在反覆的過程中是可能引起效能瓶頸的。
其餘內容請看原站～～