RX：一種新型支援隨機存取的 JSON 替代方案

背景

RX（或稱 REXC）是由 nvm.sh 與 js-git 的創作者 creationix 所開發的一種新型隨機存取資料格式，旨在解決 JSON 在處理大型數據集時的效能瓶頸。傳統 JSON 必須在讀取前進行完整的解析與反序列化，這在面對數十 MB 甚至更大的檔案時會消耗大量記憶體與運算資源。RX 透過延遲解析與指標技術，讓開發者能像操作普通 JavaScript 物件一樣存取資料，卻無需預先載入整個檔案，實現了近乎零堆積記憶體分配的高效能表現。

社群觀點

在 Hacker News 的討論中，社群對於 RX 的定位與實用性展開了多層次的辯論。部分開發者質疑在效能敏感的場景下，為何不直接使用 Protobuf、FlatBuffers 或 Cap'n Proto 等成熟的二進位格式。對此，作者 creationix 解釋 RX 試圖在二進位的高效與 JSON 的易用之間取得平衡。他強調 RX 採用 ASCII 友好的編碼方式，這意味著它雖然是結構化格式，但仍具備可複製、貼上的特性，這在開發工作流中極具優勢。他認為當 JSON 檔案大到一定程度時，人類本就無法直接閱讀，此時 RX 提供的隨機存取能力與內建的查詢工具，比單純的文字可讀性更具價值。

關於「掉入式替換」的宣稱，社群也提出了技術性的挑戰。有留言指出 RX 解析後回傳的是唯讀的 Proxy 物件，這與 JSON.parse 產生的可變動原生語義不同，若既有程式碼依賴物件的變動性，則無法直接替換。作者坦承這一點，但補充說明 RX 的核心價值在於處理唯讀的大型建置產物，例如 worker 節點需要查詢的大型部署清單。此外，也有討論提到 RX 的壓縮機制，例如它如何處理重複的鍵名。作者指出 RX 透過指標去重與鏈式路徑壓縮，能有效縮減體積，這讓它在某些場景下比 SQLite 更輕量，卻比傳統 JSON 更快速。

另一派觀點則聚焦於格式的標準化與生態系。有評論者認為，雖然 RX 的設計優雅，但若要成為真正的 JSON 替代方案，需要更嚴謹的格式規範說明，而不僅僅是程式碼註釋。同時，也有人分享了類似的技術經驗，提到如 OpenStreetMap 的二進位格式或 Rust 的 rkyv 函式庫，這些案例都證明了「無需解析即可存取」的設計模式在處理海量數據時的必要性。儘管有人認為 RX 處於一種「兩頭不到岸」的尷尬位置——既不如二進位格式節省空間，也不如 JSON 直觀——但多數參與者仍對其在特定工程問題上的創新表示肯定。

延伸閱讀

在討論過程中，社群成員提到了幾個與 RX 理念相近或可供比較的技術資源。其中包括 Rust 生態系中知名的零拷貝序列化函式庫 rkyv，以及 OpenStreetMap 所使用的二進位資料格式，後者同樣強調在不載入全部記憶體的情況下進行高效讀取。此外，針對 XML 的高效交換需求，留言中也提到了 EXI（Efficient XML Interchange）標準，作為在保持結構化優勢的同時提升傳輸效率的參考案例。