諾蘭勞森（Nolan Lawson）在 2026 年 10 月 3 日寫了一篇談「用平台」的文章，隔天在 Hacker News 收到 301 則留言。這篇把譯文和討論整理放在一起，方便一次讀完。
原文：https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/
討論串：https://news.ycombinator.com/item?id=49950554
原文翻譯
多年來，Web 標準、效能與無障礙的倡議者不斷懇求 Web 開發者「用平台」。我自己也常常是倡議者之一。
論點很簡單：瀏覽器能幫你做的事，為什麼還要用 JavaScript 自己造輪子？你自己造的東西，效能跟可用性大概都比不上瀏覽器開箱即給的。
不過我覺得值得站到對立面想一次，哪怕只是為了理解那些平台懷疑論者是怎麼想的。如果「用平台」這麼理所當然，為什麼還有一堆人需要被說服？
最直接的原因是歷史。很長一段時間，瀏覽器都在追趕壓在它上面的生態系。jQuery 這類函式庫補上了關鍵缺口，瀏覽器才慢慢實作出對等的 API。即便如此，你還得等 IE6 這種落後者自然淘汰，才能真正用上。時至今日，多數瀏覽器都是常青版（Safari 有沒有算進去可以爭辯，不過一年更新約 7 次也不算差），但直到 2020 年代左右，Web 開發者面對的，仍是坑坑疤疤的 Web。在那種環境下，自己動手是合理的選擇。
另一個原因是熟悉度。當你習慣去 npm 找 React 元件，遇到什麼問題都會先伸手拿那一套。你在 npm 搜尋 sticky positioning，不會有哪個套件跟你說直接用 CSS position sticky 就好。
就算標準已經完整，npm 上的函式庫，仍在補框架人體工學與底層平台間的落差。我一直覺得很有意思：很多 React 開發者堅持用 JSX 跟 React 慣用寫法，覺得原生 DOM API 很噁心，卻很樂意用底層函式庫，而那些函式庫裡到處都是原生 DOM 操作。舉例來說，虛擬列表函式庫可能為了效能大用原生 DOM API，同時對外暴露更高階的抽象，讓新手更好理解。某種意義上，React 元件生態系形成了一種自然分工：懂比較多的人，把陌生的平台 API，包裝成比較熟悉的形狀。
一部分效應也是文件造成的。很多 npm 套件都有用心寫的 README 或官網，附範例、教學、截圖。反觀 Web 平台的文件，在 MDN 成為公認去處之前，是散落在各個部落格、StackOverflow、CSS Tricks 這類網站上的。而這些網站很多乾脆就叫你用 jQuery 或 GreenSock 這種知名函式庫。
但如果只是第三方函式庫對平台 API 之爭，我覺得還不足以完整解釋大家對「用平台」的反感。想偷懶的開發者只想要一個現成解法，不管解法來自 npm、瀏覽器，還是別人 GitHub Gist 抄來的。他們只想解決問題然後走人。但我想談的，是另一種反「用平台」的來源。
對某種開發者來說，自己動手做就是比較好玩。而且做出來的程式碼常常比較好理解，特別是當你對 Web 平台沒有百科全書級認識時。一旦你自己做出東西，還會有種 IKEA 效應，讓你想繼續維護、把玩自己手作的程式碼。
舉例來說，想像你要做一個 modal dialog。你大概知道它視覺上該怎麼運作：內容出現在螢幕上，背景還看得到但被半遮住，點外面可以關掉。於是你抓起 position absolute 跟 z-index 來定位。啊，但背景還在捲動，所以你得把 body 的 overflow 關掉。然後如果你懂一點無障礙，會想到要處理 Esc 關閉、做 focus trap、把焦點還給開啟 dialog 的那個元素，還有後續一堆細節。
對很多開發者來說，我剛講的聽起來像惡夢（一種只做出半成品的好方法）。但對很多人來說，這聽起來超好玩。想想你動手做下去能學到多少。想想你還可以加上動畫、主題、可選的關閉按鈕，做出自己的味道。不知不覺你就做出一個可以上 npm 的函式庫了。這比直接抓 dialog 元素就收工好玩多了。
而且對我們很多人來說，在 dialog 這類 API 出現之前，我們就是這樣學會 Web 平台的。現在高喊「用平台」的人，當年自己也寫過 polyfill、shim 跟函式庫。我知道，因為我就是其中之一。我在 PouchDB 的工作裡，花了好幾年做 IndexedDB、WebSQL 跟其他瀏覽器儲存 API 的工具，這才讓我有足夠信心坐進 W3C 標準會議，甚至直接對 IndexedDB 規格開 issue、送 pull request。如果不是平台有缺口逼著我去補，我不知道自己會不會有興趣走到那種程度。
當然，自己動手不全然是好事。有時純粹就是無知。特別在 Web 平台上，我覺得之所以冒出一堆明明用 CSS 解決更好、卻用 JavaScript 硬幹的解法，原因之一就是很多開發者沒花時間深入理解 CSS 怎麼運作。
公平地說，CSS 歷史上本來就難懂。有個網站叫 CSS Tricks 不是沒原因的。像 clear fix、float、min-width 0 這種招數一點都不直覺。比起搞懂 CSS 內部演算法，直接想像你要的命令式邏輯、再用 JavaScript 表達出來，常常簡單多了。再加上好幾年下來，CSS 對行數截斷、textarea 自動長高、隱藏捲軸這類常見模式，都沒有直白寫法。開發者當然用自己已經懂的工具自己造。
我甚至覺得避開平台不限於 Web。只要在自己不完全懂的平台上開發，都可能中招。舉例來說，我工作上用 ClickHouse 存各種分析資料。有一次我跟同事爭過一大坨 JSON 該怎麼存在欄位裡：他做了一套存之前先壓縮的系統，我則是把資料丟進另一個 key-value store、只把 key 塞進 ClickHouse。結果證明我們都錯了。ClickHouse 本來就會自動壓縮，而且它是欄式儲存，讓它自己處理，跨列壓縮率反而更好。而那個額外的 key-value store，只是把欄式 SELECT 早就做得到的事，用窮人版重做一次。
我是真的花時間把 ClickHouse 文件徹底讀完、再寫 benchmark 證明假設之後，才搞懂這些。最後我很震驚：我們造出來的東西，比平台開箱即給的更慢、更笨重。跟 JavaScript 和 Web 平台的相似之處，實在很難忽視。
我相信不管你是 iOS、Android 開發者，遊戲引擎上開發的人，其實任何在某種平台層上開發的人，大概都有類似故事。這也是為什麼會有老練資深工程師這種刻板印象：能把 junior 那坨華麗糾結的程式碼，換成一行就搞定。你懂得越多，就越能運用對整個系統端到端的理解，只留下最小的貢獻，長期下來維護負擔也最小。
整篇文章我一直在很努力不談 AI，但我當然忍不住想：AI 寫程式會怎麼影響這個現象。我同時有樂觀跟悲觀兩種看法。
樂觀的看法是，因為 LLM 對你用的平台有百科全書級知識，它能針對含糊的需求，精準挑到對的平台 API。而且因為這個解法大概比 userland 程式碼更快、更正確，經過嚴格測試跟 benchmark 後，agent 會偏好它。再者，開發者自己沒動手寫 code，IKEA 效應也就消失了。
悲觀的看法是，因為 LLM 超愛重複造輪子，例如無視已經存在的 helper function，硬要自己再寫第 N 個，自幹、非平台慣用風格的程式碼會暴增。開發者不會叫 agent 測夠、試夠多種替代方案，直接就把第一版草稿 commit 了。而且因為永遠可以再加迴圈，agent 會不斷在一個根本不該存在的過度工程解法上疊床架屋。
我自己用 AI 寫程式，兩種現象都看過。我想相信模型跟寫程式 harness 越來越好之後，會慢慢偏向樂觀的那一端，但我不敢打包票。
總之，這就是我又臭又長、而且有點自相矛盾的感想。當口號我很愛它，因為它精準說中了我看到糾結程式碼時的心情：作者要是多懂一點底下的層次，事情會優雅多少。但同時，我也當過那個作者，也感受過寫出又美又亂的程式碼，那種快樂，所以我覺得值得理解這些開發者從哪裡來。正因如此，我相信只要還有平台，就會一直有人喊用平台。
HN 討論整理：301 則、73 個頂層串
我把 301 則留言全部讀完。罵聲壓倒性指向兩件事：原生元件殘缺，以及 WebComponents 難用。不是不愛平台，是平台給的不能用。
原生元件殘缺是最具體的罪狀
datalist、combobox、date picker、dialog 幾乎被點名一輪。roncesvalles 開火，說瀏覽器實作爛到不能用。usernomdeguerre 補刀，說根本沒有可搜尋又完全無障礙的 combobox，只能離開平台。date picker 只能設 min 跟 max，不能禁特定日期，JimDabell 說只開平日的需求一來，整組只能丟掉重做。dialog 點 backdrop 預設不關，closedby 支援零散，focus 管理不如成熟方案。bastawhiz 的例子最慘：把 100KB 的 React date picker 換成 datetime-local，24 小時內收到 Firefox 加 NVDA 使用者投訴要求換回去。
WebComponents 被罵最慘
jchw 說它是設計糟糕、怪異難用的 API。JimDabell 說 25 年前端生涯只想 quit 兩次，一次是 IE6，一次就是 WebComponents。每個 shadow root 都要重掛 CSS reset，box-sizing 不一致，slots 要 host，attribute 同步逐次觸發，HTML 字串沒有檢查還有 XSS 風險。辯護方只剩兩招：免框架，以及十年老 DOM 碼比沒人維護的 Backbone 好維護。原文一次都沒有提到 WebComponents，是討論串自己歪過去的。
React 霸權：動量還是技術
josephg 說 React 靠文件、影片、conference、資金堆出動量，VDOM diffing 是純 overhead，大家都用錯就代表設計有缺陷，推薦 Solid。jchw 反擊，說 JSX 只是薄糖，可以換 Preact，編譯器也是 trade-off，百萬項 file grid 的瓶頸是瀏覽器捲動區而不是 React。歷史派還原現場：React 出生時是 jQuery 加 AngularJS 雙向綁定地獄，單向資料流在當年是解藥。
客製化剛需：怪設計師還是怪使用者
littlecranky67 說沒見過 UX 設計師對原生滿意。qurren 說他就是想要圓角按壓感，平台給不了。amelius 說老闆站在旁邊叫邊框左移三畫素，正確答案是那要整個重寫。nfw2 反轉視角，說不是設計師的錯，是使用者要的，設計師只是拿錢在乎細節的人。Spivak 說 Figma 畫素級還原正是 web 勝因，joefourier 則說 web 贏是因為免安裝 SaaS，不是畫素。
平台該多小，Safari，以及 AI
serbuvlad 開了最長的哲學串，主張 web 該像 Unix 只給小組可組合原語，高階 widget 留給函式庫。charcircuit 回嗆，那標準函式庫幹嘛實作 sort，平台的重點是讓人好用。Safari 方面，一派說 Apple 把瀏覽器綁 OS 更新，老 iPhone 一堆，另一派拿出數字，說 Safari 16 全球只剩約 0.25，使用者不該為極少數付機會成本。AI 方面，兩種現場都有人回報：AI 隨手生出 800KB React 是常態，但不懂 console 跟圖學，就看不出 AI 生的多 GB pixel buffer 有多荒謬。
一頁看懂：作者與網友論點
手機上覺得擠可直接開：https://static.blog.derekhsu.net/use-platform
我的 take
讀完 301 則，最有說服力的，其實是原文沒展開的那句：平台制定者要先看 desire paths 再鋪路。scroll-driven animation 這類能力，都是民間 hack 成風、標準才跟進。反過來，先丟一個半殘的原生元件，再喊大家用平台，不會有人理。AI 之後這個落差可能更大：第一版草稿越好生，越沒人想回頭試原生。
以上譯文與整理，原文版權歸原作者所有，轉載請附原文連結。