[筆記] 2025 JSDC 回歸小聚

第一次參加 JSDC 的實體小聚，收穫滿滿，決定整理成一篇筆記寫在 Medium 上，強迫自己不要船過水無痕 😎

一、MonoRepo 實戰指南：工具選性與 OXC 性能突破 — Michael

🎯 問題背景：

只改一行 code，卻要跑靜態檢查快十分鐘？工具做了重複的事、CI 卡住？這是許多前端團隊在多套工具鏈下常見的痛點。

✅ MonoRepo 的優點：

1. 同步 UI 元件
2. 共用商業邏輯
3. 統一開發工具鏈、維護成本低

🛠 MonoRepo 工具選型建議：

• 3–5人小團隊：pnpm Workspaces 足矣
• 5–10人中型團隊：Turborepo（快取強、與 Next.js 相容佳）
• 10人以上大型團隊：Nx（歷史悠久、功能穩定、適合複雜架構）
• Next.js 專案：建議使用 Turborepo，除了良好的 MonoRepo 管理能力外，也整合了 Serverless 架構下的快取機制（caching），在部署與開發效率上表現出色。
• 其他框架（如 Angular、NestJS、React SPA 等）：推薦使用經過社群長期驗證、超過五年穩定發展的 Nx，擁有完善的生態系與彈性的 plugin 系統。

🚀 效能突破：OXC (Oxidation Compiler)

• 由 尤雨溪創立的 Void Zero Ecosystem 所開發
• 用 Rust 寫的高效 AST 分析工具
• 講者實測原本 CI 跑兩小時 → OXC 降到只需二十分鐘！
• 傳統工具如 ESLint / Prettier / TypeScript parse 都是 JS-based，彼此無法共用記憶體。
• Shopify 專案導入 OXC 後，原本需時 75 分鐘的靜態分析流程，縮短為 僅需 10 秒。
• Airbnb 測試中包含 126 個檔案，分析時間也只需 約 7 秒，展現極致效能。

⚠️ 使用注意事項：

• 不建議目前直接用 OXC 取代 ESLint（規則尚未完整覆蓋）
• 可搭配 eslint-plugin-oxlint，這是一個讓 ESLint 可以呼叫 OXC 引擎的 plugin，作為過渡方案，讓開發者保留 ESLint 生態的同時享有部分 OXC 效能，補強目前 OXC 規則尚未完全覆蓋 ESLint 的空缺。

eslint-plugin-oxlint 補充說明：允許在現有 ESLint 設定中，使用 OXC 提供的 Lint 核心。本質上是 ESLint 的 wrapper，將 OXC 整合進來用作解析器與規則執行引擎。不過目前穩定性仍在觀察中，且尚未覆蓋所有規則。

• 建議先在 風險低的專案試行，觀察成效與相容性

目前還是不太建議直接把 Eslint 換成 OXC，因為 Eslint 規則如果少會蠻麻煩。OXC 有因應方案 eslint-plugin-oxlint。（這部分不太確認？）

做這些嘗試要注意使用風險性較低的專案。

🧭 建議使用 OXC 的策略 — Progressive Migration Strategy：

• Progressive Learning：從單一專案開始導入，逐步理解 MonoRepo 概念與架構
• Progressive Integration：優先共用 UI 元件，再逐步整合商業邏輯，最終統一工具鏈
• Progressive Tool Selection：根據團隊規模選擇 pnpm → Turborepo → Nx
• Progressive Performance：建議可儘早導入 OXC，在風險可控的情境下測試其高效能潛力

💬 Q&A：

Q：目前 OXC 發展還早期，不太穩定，請問講者對於 OXC 發展的看法？

A：OXC 為尤雨溪開發，初版就有如此大的成效，是未來趨勢之一，未來可能逐漸替代部分 JS 工具。推測 Eslint 未來在基本情境下應該會被涵蓋在 OXC，除非很複雜的情境才會另外單獨設定。

二、React Re-render 3 大優化方式 — ThisWeb Kun

1️⃣ 狀態下移

• 將狀態放在真正需要它的 component 裡，避免整層重渲染
• 判斷時機：當 state 僅少數元件使用，就可以考慮往下移

2️⃣ useMemo/useCallback 濫用無效

正確使用時機：

• 多個 useEffect 用到同一物件或函式
• 該運算邏輯成本高昂（建議測量時間）
• 傳遞物件或函式到子元件（避免每次都產生新 reference）

React.memo 常見失效原因：

1. props 是物件或函式，每次 re-render 都是新值，memo 無效
2. props 是 children，children 每次 re-render 都是新物件，若 children 不記憶化，memo 無效

3️⃣ Context 全局炸彈

1. 使用 Context 提供狀態時，一旦更新，所有訂閱的子元件都會 re-render

（註：第三點演講時未講得太明確，這裡筆記是根據講者簡報內容推測）

三、關於 ServerSide Render 的 Auth 機制踩坑分享 — 竹子

當我們選擇使用 SSR 架構（Server-Side Rendering）來開發網站，最常遇到的挑戰之一就是「身份驗證與授權」機制的設計。這場分享由竹子講解 SSR 架構下遇到的實戰問題與思考。

🔄 MPA、SPA、HRA 快速回顧：

MPA（Multi-Page Application）： 傳統網站架構，每次點擊連結都會向伺服器請求新的 HTML 頁面。適合 SEO 要求高、頁面數量多的網站，例如新聞、購物平台。

SPA（Single-Page Application）： 僅載入一次 HTML，之後透過 JavaScript 動態更新內容，不重新載入整頁。用於互動性高、前後端分離的應用，如 Gmail、Facebook。

HRA（Hybrid Rendering Architecture）： 結合 SSR（Server-Side Rendering）與 CSR（Client-Side Rendering），根據情境選擇渲染方式，兼顧 SEO 與使用者體驗。Next.js 是典型實作範例。

🔧 現代 SSR 工具：Next、Nuxt

✅ SSR 的優點：

• SEO 友善：搜尋引擎爬蟲更容易抓取 SSR 輸出的完整 HTML 渲染結果。
• 加速 SCP（首次內容呈現）：用戶可以在網頁尚未互動前就看到完整內容，尤其在慢網路上差異更明顯。
• 安全性更高：敏感資料放到 Server 處理，提高網站資訊的安全。

🔐 Auth 機制的常見問題與坑：

1. Token 要存哪裡？

前端普遍習慣把 Token 存在 localstorage，但 SSR 下，Server 取不到 localstorage 的資訊。

SSR 架構下，無法從伺服器端取得 localStorage，因此不能把 Token 存在 localStorage。通常建議將 Refresh Token 存在 HttpOnly Cookie，而 Access Token 則根據情境保存在 memory 或前端 Cookie 中。

2. 到底要在 Client 還是 Server 發出請求？

3. Refresh Token

在 Next.js 使用 React Server Component (RSC) 的情境下，頁面是「串流渲染（streaming）」的，因此 Server 在渲染過程中無法中途修改 Cookie。

因此，有些實作會改用 Redis 或其他後端儲存，把使用者 session 狀態（像是 access token）存在 Redis 裡，供之後的 API 或 RSC 使用。

若你用 Next.js + RSC + SSR，用 Redis 管理 session 更穩定也更安全。

4. 當需要開 SSR Serverless 微服務時，怎麼開更多？

🧠 思考：你真的需要 SSR 嗎？

在 SSR 架構下，原本簡單的事會變得複雜，真的需要 SSR 嗎？SSG、CSR 是否也能解決呢？

四、用 JavaScript 來開發各種 AI 應用的經驗與當前生態 — Ray 貓

（註：這部分知識落差較大，筆記內容有缺少）

如果需要做多個供應商的切換？

格式化輸出：即使有定義 schema，還是無法做到完全穩定，要寫好容錯

用 JavaScript 串接多個 AI 供應商：

1. LangChain： 幫你「組裝」AI 應用的流程，比如串 GPT + 搜尋 + 記憶等步驟，像樂高積木一樣搭起來。
2. LlamaIndex： 幫助你把自己的資料（像是 PDF、Notion、資料庫）整理好給 AI 查詢。 你問問題時，它幫你從資料裡撈出答案給 GPT 回答。
3. Flowise： 視覺化工具，讓你拖拉元件、快速打造 AI 聊天機器人，不用寫太多程式。

五、曾經我只會 jQuery，現在我在跟 AI 搶飯 — 泡泡

AI 時代不用太焦慮要學很多新技術，多學習知識才是最重要。

讓 AI 幫助我們更快上手，甚至是讀 source code。