12 年前 (2013)，我有幸擔任第一屆的 WebConf 講者，12 年後，很開心再次受邀擔任 WebConf 講者。

這次因為得到 2024 iTHome 鐵人賽的 JavaScript 組冠軍，所以洧杰邀請我上台分享奪冠的主題：Web API，一開始其實很猶豫，總覺得沒有搭上 AI 熱潮的題目，不會有人想看，但洧杰給了我非常正向的安慰：

雖然還是有搭配 AI，但至少讓我能堅定做 Web API 這個題目，不再胡思亂想各種發散 XXD

與 12 年前的差異

我只能說，我進步了！

但老實說，都過了 12 年了 XXD，期間也有擔任過其他的研討會講者，如果還沒進步真的該打屁股惹

不過 12 年後確實有個最大的優勢：我是第二天的中午場，所以可以吸取非常多大大的簡報內容與演講風格，作為我的參考與修正方向

我第一天聽完後，就覺得自己準備的內容有點淺，順序好像也不太流暢，所以回家就大改簡報改到凌晨三點，這可能是很多講師的通病 XXD，應該很多講師都是前一天開始弄簡報弄到看日出 哈

AD

今年的主題：願 Web API 原力與你同在

你是否曾經為了深層拷貝一個物件而引入 lodash？為了顯示一個簡單的 Modal 而安裝了 react-modal？很多時候，我們在開發功能時，習慣先去找套件，習慣先 npm install，可能不是因為我們真的需要用套件，而是我們不知道瀏覽器提供的 Web API 已經能做到這些事了

我戲稱，這是一個最好的時代，因為隨著各大瀏覽器廠商透過 Interop 專案的推進，以及 Web Platform Baseline 標準的確立，能夠使用的 Web API 只會多不會少

延伸閱讀：瀏覽器互通專案 Interop 2023 成效佳，Interop 2024 鎖定 17 項技術

如果你也想嘗試用原生的 Web API，一開始可能會碰到以下三個決策時的困境：

Dev Advisor MCP

所以我做了一個 Dev Advisor MCP，他是一個基於 AI 的 MCP 工具，可以協助我們進行技術決策。

此外，我希望他能做到以下三件事情：

  • 自動掃描：檢查專案程式碼，找出可以改用 Web API 的地方
  • 即時查詢：整合 Can I Use、Baseline 與 MDN 資料
  • 風險評估：提供瀏覽器支援度與 Polyfill 建議

有興趣的朋友可以試著安裝 MCP，我提供了三種方式，包含 npm 安裝、npx 執行，以及 git pull 後在本地執行：

方式一：使用 npm 全局安裝

首先全局安裝：

npm install -g @mukiwu/dev-advisor-mcp

▼ 然後在 Claude Desktop (~/.claude/config.json) 或 Cursor IDE 中配置

{
  "mcpServers": {
    "dev-advisor": {
      "command": "dev-advisor"
    }
  }
}

方式二：使用 npx

▼ 然後在 Claude Desktop (~/.claude/config.json) 或 Cursor IDE 中配置

{
  "mcpServers": {
    "dev-advisor": {
      "command": "npx",
      "args": ["-y", "@mukiwu/dev-advisor-mcp"]
    }
  }
}

▼ 此時用自然語言詢問他關於 web browser api 的資訊，他就會開始執行 MCP tools

系統性的決策框架

BUT ! 工具只是一個手段，但他可能不是長遠之計，深究其底層，還是希望有一套系統性的決策框架：R.E.A.D.

1. Review

不要等到專案爆炸才優化。定期打開 package.json，對每一個 dependency 自問：「我們真的還需要它嗎？」

2. Explore

當你有新需求時，改變搜尋關鍵字，不要搜尋 javascript library for deep clone，改搜尋 MDN deep copy，MDN 會告訴我們 structuredClone 這個原生 API 已經存在，而且比自己手寫的遞迴函式更快、更安全

3. Analyze

我們可以使用 Basline 協助分析，Baseline 是由 Google、Mozilla、Apple 和 Microsoft 共同定義的標準，它將瀏覽器支援度分為三個明確的狀態，協助我們更好的選擇技術

  • Widely Available 廣泛使用：自新互通日期起已滿 30 個月，大多數網站都能使用這項功能，不必擔心支援問題
  • Newly Available 新功能：這項功能支援所有核心瀏覽器，因此可互通運作

4. Document

團隊合作中，最怕每個人寫的語法不同，所以如果可以，盡量建立一份內部的 Cookbook，舉個例子，可以把如何用 <dialog> 寫出符合公司設計規範的 Modal，標準化成一段 Snippet。

未來新同事報到就不會因為覺得原生難寫，又偷偷把 react-modal 裝回來 XXD

第一性原理

第一性原理，是我在這張簡報最想分享的核心概念

這個詞大家可能常聽到 Elon Musk 提起，聽起來很哲學，但在前端開發的現場，它其實是一個非常務實的防禦工具

平常我們接到一個需求，比如說要做一個拖曳排序的功能，我們大腦的第一直覺通常是：「有沒有哪個好用的套件可以裝？」或者是「上次那個專案用的是啥」... 這樣的類比思維，也就是別人怎麼做，我就跟著怎麼做

這很安全，這沒什麼問題，但也讓我們容易陷入依賴的慣性，而第一性原理要求我們做的，是打破這種慣性，把問題拆解到只剩最基礎的本質

也許我們在實作前，可以試著問自己拖曳功能的本質是什麼？它其實就是監聽滑鼠的位置，並改變 DOM 的順序

當你理解了本質後，我們可以再往下問：「如果不依賴任何別人的程式碼，瀏覽器的 web api 有沒有提供這樣的功能呢？」

當你開始這樣思考，你就會主動去探尋，然後會發現原來 HTML5 早就內建了 Drag and Drop API

這就是第一性原理在技術決策上的應用：我們跳過那些中間人疊加的抽象層 (Abstraction Layers)，直接運用最底層的積木(也就是 Web API) 來解決問題

當你習慣用第一性原理思考，你就不會再被特定的框架或套件綁架。因為框架會過時，但瀏覽器的底層標準，才是我們真正能夠長期持有的資產

共勉之，願 Web API 的原力與你同在

延伸資料