「這個元件我們自己做就好吧？」這句話我每次聽都會有點警覺。按鈕當然很快，接著是 combobox、日期選擇器、錯誤狀態和鍵盤操作，半年後才發現團隊不是做了一個元件，而是認養了一套 Design System。Nuxt UI v4 出來後，我又重新想了一次：我們到底是在買方便，還是在借一筆之後要用客製成本償還的債？
Nuxt UI v4 把原本分開的免費版和 Pro 內容整合，提供超過一百個元件、模板與 Figma Kit。對小團隊來說，這能省下不少從按鈕、表單一路做到 modal 的時間。
現成元件庫的優點是快、常見互動較完整，缺點則是畫面容易帶有相似風格，客製到很深時也可能開始和原本設計打架。自建 Design System 的自由度高，但需要有人長期維護文件、無障礙和各種狀態。
多數專案不用急著二選一。可以先用 Nuxt UI 處理基礎互動，再透過 theme 和包裝元件建立自己的視覺規則，把真正有品牌特色的部分留給自己。
如果團隊只有一兩位前端，從零維護 date picker、combobox 和表單錯誤狀態，通常不是最划算的投資。反過來說，若產品有大量特殊互動或嚴格品牌規範，現成元件改到最後也可能比自己做更辛苦。這篇不用選邊站，把人力和產品差異放進來看就夠了。
還有一個常被低估的成本是升級。自建元件要自己修瀏覽器和無障礙問題；採用套件則要跟著 breaking changes。決定前除了看元件數量，也可以看看 changelog、維護頻率，以及團隊能不能接受它的 API。
我習慣先做一個「最難客製的元件」小樣，而不是先展示 Button。把產品真正複雜的 combobox、表格或表單錯誤狀態做出來，才能看出 theme API 夠不夠、DOM 結構能不能配合測試，以及設計稿到底需要多少 override。按鈕漂亮通常證明不了什麼。
若最後採用套件，我也會包一層很薄的產品元件，但不會把所有 props 原封不動再轉一次。只包真正需要固定的視覺和行為，否則 wrapper 反而會成為升級時的第二套 API。