看到 Tailwind Plus 開始支援 Vanilla JavaScript，我第一個反應其實是笑了一下：前端繞了一大圈，現在又開始宣傳原生 JS 了？但想到自己只是做一個 dropdown，卻曾經得先確認 React runtime、hydration 和 component boundary，又覺得這條回頭路好像很合理。有些互動真的沒有複雜到需要整個框架出場。
Tailwind Plus 過去常讓人聯想到 React 或 Vue 元件，但 2025 年加入 Vanilla JavaScript 支援後，也可以不綁特定框架來使用互動元件。
這件事反映了一個簡單趨勢：有些 dropdown、dialog、tabs 並不一定需要整套 React。HTML、CSS 和少量 JavaScript 已經足以完成，而且更容易放進不同技術的網站。
當然，複雜應用程式仍會從框架的狀態管理和元件模型得到很多幫助。重點不是回到「全部手刻」，而是不要因為一個小互動，就先把整個網站綁在某個框架上。
這對後端模板、傳統 CMS 或像 Astro 這種以 HTML 為主的網站特別實用。需要互動的地方只加少量 JavaScript，其餘頁面不用為了幾個元件一起載入框架 runtime。
不過 Vanilla JavaScript 並不自動等於更輕。若元件各自帶一份重複邏輯，最後仍可能變大。真正值得看的是輸出多少程式、互動是否好維護，而不是看到「無框架」三個字就先判定比較好。
我會先看互動的生命週期。如果元件只在開啟、關閉之間切換，原生 JS 很舒服；如果狀態會跨頁共享、和權限及 API 串在一起，框架提供的資料流就開始有價值。用程式碼行數判斷要不要框架，通常會漏掉後面維護狀態的成本。
另一個檢查點是 cleanup。事件監聽、focus trap 和動態插入的節點如果沒有一致的卸載方式，幾個「很小的 script」疊起來也會難查。無框架不是無架構，只是架構要由團隊自己說清楚。