前言
JavaScript 發展至今帶著許多歷史相容性包袱。過去為了確保在各種環境執行，我們發展出許多複雜的工具鏈與撰碼模式。但隨著瀏覽器支援度的飛速進步，許多先前認定的「最佳實務」已經不再必要，甚至成為效能與維護上的冗餘。
本文旨在說明現代前端的撰碼實務建議，提供給想寫現代前端程式的開發者參考。
不建議使用非 JS 語言的轉譯器
許多現代語言（如 Rust, Go, Kotlin）都有將程式碼編譯成 JavaScript 等效代碼的功能。這聽起來很美好，開發者似乎可以避開 JavaScript 的特性，直接用熟悉的語法實作產品。
然而，這類轉換並非「免費午餐」。對瀏覽器而言，JavaScript 是它的「組合語言」。為了在 JS 中完整模擬其他高階語言的語法，編譯器往往需要在轉出的代碼中插入大量的 Runtime Code（執行期程式碼）。
這些額外代碼是開發者無法掌控的「黑箱」，不僅增加檔案體積、造成效能損耗，還可能隨著原語言版本更迭而變動，導致與原生 JS 程式合作時出現相容性問題。因此，除非是現成的高度複雜邏輯需要原封不動搬上網頁，否則不建議透過轉譯器來撰寫前端業務。
不用守著 ES5 語法
過去為了考量舊版瀏覽器（如 IE），ES6+ 的語法曾被視為「有毒」的。為了防禦，開發者習慣使用 IIFE（立即執行函式）或複雜的 Closure（閉包）來模擬模組化。
但這些模式本質上是在補齊語言的缺失，而非為產品核心功能服務。根據 Can I Use 的數據，ES6 及其模組化規範（ES Modules）已獲得絕大多數環境的廣泛支援。在現代專案中，建議直接採用 import / export 與 class 等原生語法，這能讓程式結構更清晰，也能讓瀏覽器更有效地進行最佳化，不再需要回頭寫 ES5 程式碼。
不需要使用 Babel 進行等效轉換
承上所述，在專案中強制引入 Babel 來將程式碼「降級（Downleveling）」到 ES5 往往是不必要的。Babel 是因應 ES5 到 ES6 過渡期而生的解決方案，而這個工程議題現在已由瀏覽器本身解決。
現在除了少數極舊的企業內網環境，Babel 本身已逐漸成為過去式。現代工具鏈（如 Vite, esbuild）的角色已經轉變為「型別剝離（Type Stripping）」與「打包」，而非重寫你的語法。
只加入必要的 Polyfill
Polyfill 的本質是模擬瀏覽器不支援的 Web API。對於已經支援的環境來說，那段代碼就是純粹的冗餘。
現代實務建議「精確引入」：不需要載入一整包 Polyfill 全家桶，只要針對產品核心功能（例如用到較新的 Array 方法或 Fetch API）加入必要的補丁，讓業務能順利進行就夠了。
可以用 Erasable TypeScript 輔助撰碼
雖然不建議將其他語言轉譯為 JS，但 Erasable TypeScript 是個極佳的例外。
Erasable TypeScript 是指 TypeScript 的一個子集。它的原則是：所有的型別標註在編譯後都會完全消失，不會在 Runtime 插入任何代碼。 實際上得到的，就是純粹的原生 JavaScript 程式碼。
當我們使用它時，是在利用 TypeScript 的型別系統對 JavaScript 做「靜態程式碼檢查」。它能幫你在開發階段抓出錯誤，但最終跑在瀏覽器上的代碼是透明且可預期的。
注意： 為了確保「可擦除性」，開發者應避開如 Enum（列舉）、Namespaces（命名空間）或 Parameter Properties 等少數會在編譯後產生額外代碼的特性。只要遵守這些規範，你就能享受型別安全，同時保有原生程式碼的精簡。
結語
現代前端開發比以前簡單多了，大原則就是：
ES6+ JavaScript + Erasable TypeScript
擁抱標準，減少對黑箱工具的依賴，會讓你撰寫下一個前端專案更愉悅且更高效。