對於許多前端工程師來說，JSX 已經成為定義使用者介面（UI）的標準語言。無論是 React、Preact 還是 SolidJS，大家都習慣在 JavaScript 中撰寫類似 HTML 的標記。然而，JSX 本質上只是將標記轉換為函數呼叫，許多 UI 常見的邏輯控制（如條件判斷、迴圈）必須依賴 JavaScript 的原生語法（例如 map 或三元運算子）來實現。這種做法雖然靈活，但在複雜的模板中往往會讓程式碼變得雜亂。
近期由前 React 與 Svelte 核心團隊成員 Dominic Gannaway 推出的 TSRX，試圖解決這個痛點。TSRX 被定義為一個 TypeScript 的語言擴充，它的目標不是要取代某個框架，而是要成為一個不綁定框架（Framework-Agnostic）的 JSX 繼承者。
理解 TSRX 的核心邏輯：從慣例轉向語法
在傳統的 JSX 中，我們處理清單時必須寫 map，處理條件顯示時必須寫三元運算子或邏輯與運算子。這些是開發者的慣例，而非語言本身的語法。TSRX 的核心理念是將這些常見的 UI 模式直接提升到語法層級。
TSRX 引入了聲明式的控制流標記，例如使用 @if 處理條件、@for 處理迴圈、@switch 處理多分支邏輯，以及 @try 用於錯誤處理。這意味著開發者不再需要在標記中穿插大量的 JavaScript 運算式，而是使用更直觀、更像模板語言的結構來定義介面。
此外，TSRX 還內建了許多提升開發體驗的特性，例如屬性簡寫（Prop Shorthands）、延遲解構（Lazy Destructuring），以及直接在組件中定義 Scoped CSS（作用域樣式）。後者透過編譯器將 CSS 選擇器加上唯一雜湊值（Hash），確保樣式不會污染到其他組件，解決了前端長期以來對 CSS 命名衝突的擔憂。
一次撰寫，多端輸出：編譯器的角色
TSRX 最強大的地方在於它並不直接運行在瀏覽器中，而是一個編譯層。它會將 .tsrx 檔案解析成一個共享的 AST（抽象語法樹），然後透過不同的插件將其轉換為目標框架的程式碼。
目前 TSRX 提供了對 React、Preact、Solid、Vue 以及 Ripple 的支持。這意味著你可以用一套 TSRX 語法撰寫組件，然後根據需求將其編譯為 React 組件或 Vue 組件。這種設計將 UI 的描述與底層的運行時（Runtime）解耦，讓開發者能從框架的瑣碎限制中抽離，專注於介面邏輯。
實務影響與工程考量
對於 Junior 工程師來說，最值得關注的是 TSRX 如何影響開發流程。首先，它是以檔案為單位的採納方式。你不需要將整個專案遷移到 TSRX，而是在需要的地方建立 .tsrx 檔案，編譯後它會變成對應的 .tsx 或框架檔案，因此可以與現有程式碼共存。
在開發工具鏈方面，TSRX 已經支持 Vite、Rspack、Turbopack 和 Bun 等現代建構工具，並提供 Prettier 與 ESLint 的支持，確保程式碼品質。
然而，這種方案並非沒有爭議。部分開發者認為將 XML 類型的標記混入 JavaScript 依然是一種不夠優雅的設計，更傾向於像 Kotlin 或是 F# 那樣使用函數式建構器（Builders）來定義 UI。此外，SolidJS 的創始人 Ryan Carniato 也提到，雖然 React 開發者能藉此擺脫繁瑣的 Hook 規則，但對於強調透明度的 SolidJS 使用者來說，這種抽象層可能會掩蓋底層的運作機制。
總結與建議
TSRX 並非一個新的前端框架，而是一個旨在統一 UI 撰寫體驗的工具。它試圖在 JSX 的靈活性與模板語言的直觀性之間找到平衡。
目前 TSRX 仍處於 Alpha 階段，官方明確建議開發者僅將其用於實驗，而非直接遷移生產環境。但從技術趨勢來看，這種嘗試將 UI 描述標準化、去框架化的方向，值得每一位關注前端工程化的開發者持續追蹤。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。