[心得] JSDC 2025 簡短筆記與心得

前言#

這篇簡短記錄上週參加 JSDC (JavaScript Developer Conference) 2025 的一些零散筆記和心得，遙想去年參加了 WebConf Taiwan 2024，本來也要寫與會心得，但現在那篇還仍然在草稿中，今年 WebConf 2025 又要來了哈哈…，所以這次 JSDC 2025 決定盡快記錄一下。

雖然主辦方有提供共筆，也蠻多講者有提供簡報，這裡還是簡單記錄我聽的幾場議程的筆記，可能較為片段零散，其中如果有任何筆記錯誤的，歡迎大家回覆告訴我～

Vite: Beyond a Build Tool — 尤雨溪 (Evan You)#

第一次見到尤大大，非常感動，雖然本身是以 React 開發，但平常想快速起專案都會選用 Vite，Vite 真的很好上手好方便👍

Vite 底層的依賴工具包含 esbuild、rollup 和 swc，不過這些工具之間的協調太複雜了也可能有衝突，所以 Vite 想自己統一 bundler，而開發 bundler 是很複雜的，包含 code splitting、tree shaking、TypeScript 轉換，還要去 node module 裡面找出專案實際用到的 function 打包進你的專案。

在介紹如何統一 bundler 之前，Evan 先說明了 JavaScript 需要 build tool 的原因，為何我們不能單純地用 HTML、CSS 和 JavaScript 就完成網頁呢? 為何要把前端網頁弄得那麼複雜?

因為問題會隨著規模變大而逐漸產生。

• 當 JavaScript 檔案變大，全域變數的管理就變得麻煩 ➡️ module

不知道有沒有人經歷過以前純 JavaScript 建構網頁的時代，我們會在 html 檔案裡引用多個 script tag，而這些 script 如果有用到同個全域變數，就會變得很難管理與追蹤，那時為了管理變數，可能會用立即呼叫函式(Immediately Invoked Functions Expressions, IIFE) 將變數閉包起來，只限內部使用。這和命名空間有點關係，有興趣可參考我之前的鐵人賽文章 [Day 18] 命名空間化模式。

也因此有 JavaScript module 的出現，解決變數管理問題。

• 想讓程式重用，和他人分享➡️ package registry & manager

工程師不喜歡重複造輪子，當我們要和其他人分享自己的程式，就會需要套件管理工具，常見的如 npm package。

• 太多網路請求 ➡️ bundling

太多 HTTP 網路請求會讓一切變慢，且 HTTP 有連線的數量限制，使用者就要等很久才能取得/看到所有資源，因此我們開始思考如何 bundle 檔案，如何取得這個頁面需要的chunk 就好，避免請求多個檔案。

• syntax transform

隨專案變大，我們希望能有 type 來讓程式碼穩定可靠，因此會用 TypeScript 開發，而 TypeScript 需要轉換為 JavaScript。

• 希望一切穩定 ➡️ test runner, linter, type checkers

當專案變大了，我們希望一切穩定，所以需要寫測試、需要 linter 工具。

• style 一致性 ➡️ formatters

希望專案的格式能統一，以便閱讀，所以需要 formatters 協助排版。

• build getting complex ➡️ task runner and caching, monorepo

build 專案變得越來越複雜，甚至可能需要 monorepo。

最開始開發者會用 JS 為 JS 來寫相關工具，例如 webpack、jest，但開發這些工具後，發現 JS 不如預期的快。

所以在這時代，開發者會用 native language 為 JS 寫工具，例如 swc、oxc、esbuild、rspack、rolldown，希望能運作得比 JS 更快。但目前這些工具還是很分散，所以 vite 想提出 void(0)，建立統一的 tool chain，以 Rust 寫。

接著 Evan 介紹了他們做了什麼，包含 rolldown 的進度，Oxlint 相比 Eslint 的速度，oxfmt 相比 prettier 的速度等，就不特別詳述。

明年 Vite 8 預計引入 rolldown 作為預設的打包工具，可以期待一下!

QA 環節中，有人問 Evan 對 React Server Component 的看法，Evan 直接不諱言地說，實際價值不大😂，目前沒看到在應用上本質的優勢，反而讓開發者的心智模型變複雜。

What AI means for JavaScript developers 2025 and beyond — Tejas Kumar#

Tejas Kumar 是 Fluent React 的作者，目前在 IBM 擔任 AI 工程師，但之前也是 JavaScript 開發者，有在經營 ConTejas Code 這個 Podcast。

Tejas 從 JavaScript 開始說起，JavaScript 可以在任何地方執行，前端、後端、IoT，甚至是 PS5 的介面都可以用 JS 打造，JS 可說是最常用來創造使用者體驗的工具，JS 就是使用者體驗。

JS is user experience(UX)

更進一步來說，所有事情都是使用者體驗，Everything is UX，所謂的 Developer Experience(DX) 本質上其實也是 UX，因為 DX 就是開發者的 UX，任何工具都是為了使用者體驗。

而 JS 可解決 UX，那到底什麼是 UX? UX solves real problems for real people，什麼是 real problem 呢? 包含兩點：

• 取得資訊 getting information
• 把事情完成 getting work done

舉例來說搭捷運時，我想完成的事是「抵達公館捷運站」，此時我需要資訊知道自己怎麼抵達公館捷運站，而捷運站如何讓捷運使用者(我)有好的體驗、能提供足夠資訊，這就是一種 UX。

補個自己的小心得，聽到 UX 時其實蠻開心的，因為自己研究所時讀了一些與使用者體驗、設計相關的東西，所以本身就蠻在乎使用者體驗，當 Tejas 提到 JS 就是 UX 的時候，很開心過去所學的 UX 能和現在前端工作的 JS 有所連結，過去在設計/UX 方面上的學習沒有白費😌

那 AI 呢?

AI also solves UX

首先簡單定義下 AI agents，AI agent 可以簡單理解為：a person that has agency，而 agency 的意思就是「可以做決定」，因此我們人類也都是 agents 因為我們有 agency、我們可以做決定。

Tejas 舉例，例如他可以做「拿麥克風」的選擇，例如當別人問他數學問題時，他的大腦會想到「計算機」這個工具然後選擇拿出來計算。

既然 AI (AI agent) 和 JS 都解決使用者體驗，那他們的關聯是什麼?

Tejas 認為 AI 和 JS 的交集是 Model Context Protocol (MCP)，他示範了Langflow 的用法，例如幫他建立行事曆活動、幫他去研討會活動找他的演講時間，他都請 AI agent 幫他達成。而 JS 在這過程的角色，在於 AI agent 可以執行你寫的 JS code，JS code可以作為 MCP tool，輸入給 AI agent 執行。

進一步來說，Tejas 認為網頁的呈現形式已經改變，AI agent 可以利用 MCP 或是定義好的 tool，幫我們去瀏覽網頁，幫我們和網頁互動，最後取得我們需要的資訊呈現給我們。

未來也許人們是在和 AI agent 的對話中，取得 MCP 的產出結果然後與 JS 產出的介面互動，例如 ChatGPT 可以在聊天介面中產出地圖，然後讓你展開與其互動，你不需要自己切換不同網頁 tab，或是去地圖搜尋。一切只在一個頁面中完成。

QA 時有人問：If the future focus of JavaScript is agents, does that imply its importance in frontend will decrease? Could it even mean websites may become less significant?

Tejas 的回答是，這題可以問我們自己，你會偏好和 ChatGPT 對話就得到答案，還是偏好自己打開網頁去點擊互動。

但我自己還是偏好後者，喜歡原始的(?互動方式，改變平常習慣的互動方式，對我還是需要一些時間吧 XD

最後大力表達我對 Tejas 的愛😍，看很多人的心得都說很喜歡 Tejas，我也不例外，Tejas 是這次 JSDC 裡最喜歡的講者! 他的簡報和整個 talk 的流程非常流暢，表達幽默生動，又淺顯易懂，並且是我這次的國外講者中，我最聽得懂的英文(?，看 CodeFarmer 比喻說很像聽了一場 Tech 脫口秀，好像真的蠻像的哈哈，我也很喜歡他在後面 Panel 分享的觀點，要去聽他的 Podcast 了🤣

非常感謝 JSDC 團隊能邀請到他🙏

使用 Google Apps Script 降低部署的認知負荷 — Will 保哥#

第一次見到保哥本人，以前不知道 Google Apps Script 可以做到這麼多事情，這場最大收穫就是原來 Google Apps Script 還可以幫我們快速建立 Google 表單，並且 Google Apps Script 的程式也都可以叫 AI 寫，看來以後不需要再手動建立表單了😌。

程式碼減重：你的 Tree-Shaking 在偷懶嗎？ — SerKo#

應該是這次 JSDC 技術上收穫最多的一場。

Tree-Shaking 意思是只保留有用的程式碼。而在 tree shaking 過程中，有些沒有用到的程式，可能最後還是沒有被 tree shake 掉，還是打包進了專案中，導致檔案體積太大或是附帶上開發用程式碼，有機密洩漏問題。

首先，Vite 使用的 rollup 的 tree shaking 實現方式如下：

1. 建立 graph，建立 AST
2. tree shaking pass掃描，並在 AST 標記，標記有被使用的 function
3. chunk 分配，最後渲染輸出，最後打包的程式只會包含有用到的程式碼

接著講者介紹了為何 tree shaking 過程沒有辦法順利 tree shake，包含很多原因：

• CommonJS 可能沒辦法被精準的 tree shake，因為 CommonJS 的 require 是 runtime 的，工具比較難判斷你實際用了哪些，保險起見只好通通打包，另外如果將很多檔案共同一起匯出，那也沒辦法被 tree shake。解法是 require 時特別指定要用哪個函數，並且放到最外層 require。
• ES Module 如果寫 default export 一起 export 兩個 function，例如 export default { add, sub }，那如果其中一個 function add 沒有被用到，還是無法被 tree shake 掉。解法是單獨 export，不要用 default，例如 export {add, sub}。
• ESModule 如果用 namespace dyamic import ，目前工具還無法準確分析，無法準確 tree shake

結論是，為了更準確的 tree shake，我們應該：

• 盡量選 ESmodule
• export 避免整合多合一物件
• import 盡量使用 named import

再來 side effects 也會影響 tree shake，side effects 意思就是「影響了外部」，打包工具認為有 side effect 的 API 例如：

• fetch 或 fetchXMLHttpRequest
• 影響瀏覽器狀態，如：console、localStorage、history
• DOM 互動，包含 querySelector，querySelector 運作時會觸發瀏覽器底層的運算
• 影響 event loop 的，如：setTimeout、setInterval、Promise
• JSON.parse / JSON.stringify：這兩者可能會 throw error，有 error 就會影響外部
• throw 或是任何會 throw error 的 API，只要是會 throw error 的 API 都會影響外部，會被視為 side effects
• Object.assign

另外，Math.random 這 function 有被特別提起來說，Math.random 不是純函數，因為給相同輸入他沒辦法得到相同輸出。從微觀來看，每次執行 Math.random 都會改變 JS 引擎的 PRNG 內部狀態，微觀上來說他有 side effect；但宏觀來看，打包工具不認為是 side effects，反正它就是每次都丟出一個數字，因此打包工具眼中，Math.random 沒有 side effect，不過沒有 side effect 不一定是純函數，因為它每次輸出都會不同。

為何要介紹那麼多打包工具眼中的 side effect API 呢? 因為這會影響 tree shaking，即使 function 沒有被使用，只要 function 內有執行 console 這種有 side effects 的 API，打包工具就會將這段 function 打包進去，不會 tree shake 掉，這就導致我們檔案變過大或產生資安危機。

講者有分享如何檢測 tree shaking 是否失效，可利用一些現成的 bundle anayler，如 vite-bundle-analayer，或是 extension Treeshake Visualizer。實務開發上，我們可用一些 tree shake annotation 來告訴打包工具這是沒有 side effect 的，可以放心 tree shake 掉，annotation 如 @__PURE__ 或 @__NO_SIDE_EFFECTS__。

聽完這場才發現原來 function 或程式是否有 side effect 還會影響 tree shake，平常開發要注意一些 debug code，避免工具將不必要的 code 打包進去，另外也因為自己今年鐵人賽寫了 Functional Programming 主題，聽到 side effect 與 tree shake 的關聯有點意外，原來盡量將 function 寫成沒有 side effect 的函數，也能幫助 tree shake。

使用 Effect 提升前端應用程式的穩定性與可維護性 — 彭勝宇#

想聽這場也是因為今年讀了 Functional Programming 相關的東西，Effect 可說是個以 FP 精神設計的工具，所以想來聽聽 Effect 的介紹，這場介紹了很多 Effect 的語法以及應用方式，如何以 Effect 改寫原本的程式，來幫助我們更明確處理流程中的錯誤與支線。Effect 就像程式設計的藍圖，他是描述怎麼做，幫助我們做資源管理，確保程式萬無一失，也能輔助依賴注入，讓程式變成可替換的設計組件。

講者有提到用 Effect 時，可搭配 Generator function 和 yield* 關鍵字來寫流程判斷，它讓我們可以用命令式風格撰寫函式，不然一般的 FP 寫法很難寫 if else 這種判斷，例如可用 if (...) {yield ...} else {yield ...} 這種寫法。剛好今年鐵人賽也有介紹到 Generator Function，有一點點熟悉的感覺 XD

其他 Effect 語法介紹較多因此細節不贅述，有機會自己是蠻想嘗試用看看 Effect 的，想藉此了解 FP 的世界!

另外，Effect 有其優點，但導入專案時還是會有些問題：

• 學習曲線高，需要想辦法讓團隊適應和學習
• 可能過度工程，本來簡單的狀態管理變成更複雜

講者建議我們可逐步導入，搭配 Promise 來轉換，並在 code review 或讀書會時互相交流，同時注意「先簡單再複雜，遇到複雜問題再引入 Effect」，只需要把真正複雜的問題改寫為Effect ，其他可以維持。

記錄一下 QA 環節的幾個問題：

• Effect 和 Rxjs 的差異？

Rxjs 是處理資料流進來的事情，兩個解決的東西不太一樣。

• 導入 Effect 時，怎麼分階段導入？

用 generator 的方式逐步導入，會比較知道哪裡有錯需要處理。

• 前端使用Effect 的話不會太擔心檔案大小/空間嗎？

要看你的應用，如果是要處理複雜流程的應用，那你的使用者可能就不太在乎速度了。要確定你要解決的問題跟 react 要解決的問題是差不多程度的。（Effect 大小和 React bundle 大小差不多）

讓 AI 寫前端，我們來寫未來 — Kuro Hsu#

這場沒有從頭到尾認真聽><，但是 Kuro 大大的簡報很清楚，另外部落格文章也有記錄 QA 的回答(其中一題是我問的哈哈)，Kuro 大的回答很好，推薦大家去看!

簡單來說，與 AI 協作時我們要盡量定義好規格，在與 AI 來回溝通時持續增加 rule 來規範它，並且持續 review AI 的 code，在 AI 時代，「前端不死，真正結束的是舊的開發模式。」

Kuro 大提到，重點是產品，重點是你的產品要解決的問題，先定義好問題，然後讓 AI 執行，最後你如何檢查 AI 的成果。和後面 Panel Tejas 的看法類似，我們不能只聚焦於寫程式，而是要更關注產品和使用者體驗。

Storybook MCP: Maintaining software quality in the Vibe coding era#

這場也是有點半恍神…，簡單來說如果我們要開發一個元件，流程會是 plan ➡️ build ➡️ verify，而 storybook 這三個步驟都能涵蓋，對應 storybook 就是 doc ➡️ dev ➡️ test，而這其實也和我們與 AI 協作開發的流程類似。

Panel — How Developers Should Adapt in the AI Era — Michael Shilman / Tejas Kumar / Yusuke Wada#

這場是 Michael Shilman、Tejas Kumar、Yusuke Wada 三位和 JSDC 主持人的對談講座，好佩服主持人全英文主持對話…。

簡單記錄幾個印象深刻的討論。

AI generate code, could we become reviewer or architecture?#

Tejas 認為，工程師永遠不是只是 typing，還有 programming 和 engineering，他對於 typing、programming 和 engineering 提出了具體的差異，很喜歡這觀點，他認為 programming 是一個運作的流程，我們寫一個程式如何運作(workflow)；engineering 是一個複雜的大問題架構，需要解決多個問題，與架構有關。AI 可以幫我們 type ，但我們還是需要programming 和 engineering。

We still be engineer, but not only typing

How to maintain code quality with AI and without write by myself?#

Michael 認為要構建品質很好的軟體，需要很大的努力，AI 還是需要人去監督。也許這就是所謂 Human-in-the-Loop? 人還是需要參與其中。

How juniors to learn basic knowledges?#

Tejas 認為只用 AI 產出，而不知道基礎，是非常危險的，缺點在於你沒有學習，發生問題無法解決，且可能有你不知道的資安問題。

他認為 vibe coding 要用來加速學習但不是用來產出實際商業用產品，與 AI 協作時，重點是你怎麼看待這段 AI 產出的code，重點是要去問 AI 這段 code 是什麼意思，然後你再自己手動寫 code，遇到錯誤再問 AI，形成一個循環。Yusuke 表示這是一種 vibe learning XD。

When vibe code, what is the new essential, what is the skill becomming essential?#

Yusuke 認為有兩個是重要的，一是設計 API，二是決策制定，即使是與 AI協作，我們還是要從 AI 的建議中選一個來採納。

Michael 認為是 Testing，程式碼產出的品質還是很重要，AI 可寫出能運作的程式，但品質需要人去監督確認。

One thing learn#

這題應該是問說如果要學一個技能以保持和這時代連結(相關?)，會是什麼。

Tejas 認為第一是 User Experience，回到他早上的分享，所有事情都是 UX，第二是 Engineering，AI 不可能成為 engineer，另外還有品質保證 (quality engineering)，或說是技術品味?，身為工程師，我們要知道我們要什麼，要知道什麼是好的品質，舉例來說最好的廚師可以吃出來這是好的料理，那我們要能知道什麼是好的程式品質。想到之前聽 Summer 大大不知道在哪分享，技術品味很重要，觀點是相似的。

再來創新是 AI 無法贏過人類的，作為人，我們期待的，會被吸引的，通常都是創新(innovation)，但是 AI 沒辦法產出創新的產品，因此我們要有品質的品味，加上創新想法，這樣 AI 是無法做到也無法贏過我們的。這聽起來就是我們身為 engineer 要更重視產品，還有使用者思維。雖然是 one thing 但怎麼感覺講了很多哈哈，簡言之就是 UX、品味與創新吧(?

Crytial Ball 2028 -> still software engineer or AI orchestration?#

2028 年，軟體工程師還會存在嗎?

三者觀點類似，可能還是會存在，但工作內容會改變，Tejas 說工作沒有消失，職稱沒有消失，也許只是 shift。不過要注意的是不要當拿 jira ticket 然後單純做任務的那種人，那是最容易被消失的。

AI 熱潮下，JavaScript 開發者該怎麼走？ — PJCHENder#

第一次見到 PJ 大大也好感動，初學前端到現在都還在看 PJ 的部落格學習，每次想學什麼或查什麼，一 Google 都會先看到 PJ 的筆記都寫好了🙇

AI 時代也許我們會焦慮自己要不要學點 Python，而 PJ 說，當我們焦慮的時候，就思考一下：「我是誰？我的價值在哪？」（不論是職涯焦慮或是 AI 焦慮都適用）

PJ 讓我們重新思考 JavaScript 在做的事：

• 前端介面與互動
• 後端邏輯與整合
• 整合系統原生功能

而 AI 時代，JS 是 AI 落地的關鍵，包含：

• 生成式 UI
• AI agent
• 瀏覽器端推論

這些 AI 的應用都需要 JS 來實現。

另外也 demo 了瀏覽器內建的 Summarizer 工具，第一次認識這 API，真神奇~

在 QA 環節，PJ 有鼓勵我們在面對焦慮時，要思考你自己的定位，並放開心胸去學習。如果看到很多新 AI 資訊會焦慮的話，就關掉不要看😇，讓自己與那些資訊斷根，不要看到新資訊就不會焦慮 :)

結語#

這次 JSDC 很多講者談到 AI 時，都還是很強調基礎知識的重要性，不是有了 AI 就不需要學習基礎，反而此時基礎是更重要的，它讓我們能辨識 AI 的產出。雖然講者都說 AI 沒辦法完全取代工程師，但我有時還是會焦慮，當其他人往前跑追著趨勢或說自己用 AI 開發出什麼厲害的成品時，自己還在慢吞吞地學基礎，有點擔心落後了，不過回到 PJ 說的，也許我需要的是靜心思考自己是誰，然後適時斷根，每個人都有自己的步調😇。

第一次參與 JSDC，整體體驗非常好，場地交通方便，會場乾淨舒適、寬敞，中午健康便當很好吃，下午茶點心也很多元好吃，演講控時很好，議程安排恰當，邀請的講者都很棒，講題都很精采收穫很多，有好幾場想聽的時間撞一起，還好之後會有回放影片，真的太貼心，非常感謝這次 JSDC 籌備團隊的努力! 也很感謝所有講者的分享! 唯一可惜的是自己太害羞了，這次沒有很主動去和講者交流或旁聽別人會後QA，或是多認識其他人，明年還要參加🚀希望明年能勇敢和其他人交流聊聊~

Reference：#

• https://2025.jsdc.tw/

如有任何問題歡迎聯絡、不吝指教✍