羅馬是用來取代 Babel， ESLint， webpack， Prettier， Jest，。Rome統一了以前是獨立工具的功能。建立在共享基礎上使我們能夠為處理程式碼、顯示錯誤、並行化工作、快取和配置提供有凝聚力的體驗。Rome以前是用TypeScript編寫的，執行在Node。js 上。
為什麼改用 Rust？
我們最關心的是我們自己的生產力。
最初很難想象一個由 JavaScript 開發人員組成的小團隊能夠在幾周內掌握足夠的專業知識來構建複雜的語言工具並提高工作效率。然而，經過一些原型設計之後，我們很快意識到我們實際上可能在 Rust 中更有效率。
Rome 早期的主要決定之一是不使用任何第三方依賴項——我們甚至用我們自己的封裝了 Node API。這個決定是基於嚴格控制 Rome 內部所有程式碼的願望，以便我們可以保證效能、記憶體使用和正確性/型別安全。
然而，其中許多問題在 Rust 及其社群中得到了解決：
對第三方依賴的權衡更少 大多數 JavaScript/npm 包都必須平衡許多不同型別使用者的不同關注點。他們被迫圍繞我們不感興趣的程式碼大小和效能進行權衡。另一方面，Rust crate 通常會做出更接近我們需求的權衡。
正確性內置於標準庫和大多數流行的 crate 中。 我們正在建立自己的 API，專注於正確性，而不是使用第三方 JavaScript 依賴項。Rust 及其社群更加關注正確性，而沒有為羅馬需要擔心的邊緣情況鋪平道路。
Trait/Module 系統允許我們更好地利用依賴關係 Rust 的 trait 系統是一種強大的方式，可以在沒有開銷的情況下建立對任何資料的抽象。它允許我們深度整合第三方庫。它還允許庫建立增量更多的 API，安全地暴露更多的表面積，而無需進行重大更改。
我們意識到，在 Rust 中工作時，我們避免第三方依賴的原因並不適用。能夠在不進行權衡的情況下建立高質量的依賴關係使我們更有效率，並將導致更好、更快的Rome 。
改變的地方
當我們開始在 Rust 中進行原型設計並重新審視我們的許多基本設計決策時，這也為我們提供了重新審視我們
架構
的機會。很快，我們意識到我們想要做出一些非常大的改變。
如果您曾經花時間學習編譯器的工作原理，那麼您可能聽說過以下內容：
原始碼→詞法分析→標記
標記→句法分析→抽象語法樹
抽象語法樹→各種變換→一些中間表示
一些中間表示→程式碼生成→ { Machine，Byte，Source} 程式碼
這是編譯器如何工作的一個很好的高階心理模型，但大多數編譯器比這複雜得多。
很快你就會想要一些東西：
在開發人員進行程式碼更改時增量構建專案。
在編譯器完成工作之前請求有關某些程式碼的資訊。
即使程式碼包含語法錯誤，也要繼續提供反饋。
對於 JavaScript 和 Web 社群來說，這些責任通常被分配到許多不同的工具之間，這導致每個人一遍又一遍地以略有不同的方式實現相同的東西。Rome 希望同時成為所有這些工具，因此我們需要一個適用於所有這些不同工具的基礎。
我們研究了其他較新的編譯器是如何解決這些問題的。我們很快意識到的一個關鍵問題是我們對抽象語法樹 （AST） 的處理方法。
前端工具Rome將用 Rust改寫
