大家好，我卡頌。

前端領(lǐng)域從不缺少熱點(diǎn)，基本每過半年，就會出現(xiàn)新的工具。

在這樣快節(jié)奏的浪潮中，有個(gè)工具卻顯得格格不入，他就是Rome。

從名字中我們就能窺探出一絲端倪，看看別的工具：

• vite（法語中「快的」的意思）。
• turbopack（英語中「渦輪增壓器」的意思）。

再看看他 —— 寓意是「羅馬不是一天建成的」。

事實(shí)也如此，Rome團(tuán)隊(duì)用時(shí)一年半終于上線了第一個(gè)穩(wěn)定版本Rome v10[1]。

作為前端工具鏈工具，Rome?和那些我們耳熟能詳?shù)墓ぞ撸ū热鐅ite?、eslint?、CRA）有啥區(qū)別？未來他會一統(tǒng)前端么？

今天我們來聊聊這個(gè)話題。

Rome是什么

Rome?的創(chuàng)造者是前Babel團(tuán)隊(duì)的「Sebastian McKenzie」，后文就叫他小馬吧。

21年5月?，小馬拿了2家風(fēng)投450w刀的投資后成立了Rome Tools公司[2]。

這家公司的目標(biāo)是：實(shí)現(xiàn)一站式前端工程化解決方案，以替代現(xiàn)有的各種前端工具。

在小馬看來，當(dāng)前的前端工程化解決方案存在很多問題，比如：?

問題1:工具太多，學(xué)習(xí)成本高

對于項(xiàng)目中常用的一些工具，比如：

• 代碼格式化工具：Prettier、dprint。
• lint工具：ESLint、StyleLint。
• 測試工具：Vitest、jest。
• 編譯器：babel、SWC。
• 打包工具：webpack、vite、rollup。

要熟練使用他們并不容易，因?yàn)椋?/p>

• 需要了解不同工具如何配置。
• 需要考慮如何將這些工具整合到項(xiàng)目中。

最終，項(xiàng)目中往往充斥著各種各樣的配置文件。以至于復(fù)雜的項(xiàng)目中通常有個(gè)特殊的職位 —— 「webpack配置工程師」。

各種配置文件

很多腳手架工具（比如create-react-app）就是為了解決這個(gè)問題而生，但他們的缺陷也很明顯。

他們僅僅提供了膠水層隔離了這些工具的復(fù)雜度，但如果有個(gè)性化需求時(shí)開發(fā)者還是得直面這些問題。

而對于Rome驅(qū)動的項(xiàng)目，只會有一個(gè)rome.json配置文件以及開箱即用的最佳實(shí)踐。

問題2:性能浪費(fèi)

前端工具鏈的很多工具都有訪問AST的需要，但很多時(shí)候他們是各自為戰(zhàn)的。

比如，babel處理代碼降級時(shí)會生成AST，eslint審查代碼時(shí)也會生成AST，這就造成了性能浪費(fèi)。

另一方面，前端工具用Rust重寫已然成為趨勢。

如果能將這些工具都用Rust實(shí)現(xiàn)，并盡可能減少不必要的解析過程，就能顯著提高工具性能。

Rome的基本思路就是如此。根據(jù)小馬的計(jì)算，Rome格式化代碼的速度是Prettier的100倍以上：

benchmark

問題3:提示對開發(fā)者不友好

當(dāng)前很多前端工具是不同團(tuán)隊(duì)、不同個(gè)人開發(fā)的，所以在提示信息的準(zhǔn)確性、體驗(yàn)上各不相同。

??Rome??在「提示信息」上下了很多功夫，比如對于如下代碼：

function test(callback) {
  try {
    return callback();
  } catch (e) {
    console.log(e);
    throw e;
  }

  return 20;
}

保存為a.js，執(zhí)行如下檢查命令：

npx rome check a.js 

控制臺會輸出三段內(nèi)容。

第一段，告訴你return 20永遠(yuǎn)不會執(zhí)行：

后兩段會告訴你為什么不會執(zhí)行：

• 要不是因?yàn)閞eturn callback()：

• 要不是因?yàn)閠hrow e。

相比eslint的提示信息，Rome的提示信息確實(shí)更友好。

未來，這樣友好的提示信息會出現(xiàn)在Rome工具鏈的每一環(huán)，比如：

• 打包代碼的信息
• lint信息
• 測試信息

Rome會一統(tǒng)前端么？

當(dāng)前，Rome只提供了linter（對標(biāo)eslint）、formatter（對標(biāo)prettier）兩個(gè)工具，可以通過如下命令體驗(yàn)：

# 格式化
npx rome format <文件路徑>
# lint
npx rome check <文件路徑>

更詳盡的命令參考官方文檔[3]

如果未來Rome實(shí)現(xiàn)了他的目標(biāo)，一定是對前端開發(fā)者很有吸引力的選擇。

但是，要實(shí)現(xiàn)這種大而全的解決方案并非一朝一夕就能完成的。

而在前端領(lǐng)域，新的技術(shù)、新的框架總是源源不斷的出現(xiàn)。

同為公司級的開源產(chǎn)品，vercel?開發(fā)的next.js?雖然選擇了與Rome不同的方向（以前端框架為切入點(diǎn)），但兩者的功能點(diǎn)一定有重合的一天。

從發(fā)展路徑看，對于next.js：

• 當(dāng)前：next.js依賴webpack打包。
• 下一步：vercel投入到turbopack，next.js依賴turbopack打包。
• 下一步：turbopack為了將自身速度優(yōu)勢發(fā)揮到極致，可能會用Rust重寫其他工具鏈工具。

對于Rome：

• 當(dāng)前：主打linter、formatter。
• 下一步：開發(fā)其他工具鏈工具。

當(dāng)兩個(gè)產(chǎn)品有了功能相同的工具時(shí)，即使Rome?開發(fā)體驗(yàn)更好（假設(shè)），但早已深度耦合在Next.js技術(shù)棧的開發(fā)者要想切換底層工具鏈工具是不可能的。

不僅是vercel?，Vue?團(tuán)隊(duì)、Remix?團(tuán)隊(duì)等都是Rome的潛在競爭者。

上面說的是未來Rome?的成熟體與其他競品的競爭。而在當(dāng)前，作為linter?與formatter?，Rome的推廣也是阻力重重。

相較于eslint?、prettier?這樣帶著純正開源血統(tǒng)的開源項(xiàng)目，Rome?宏大的愿景使得那些大用戶體量的工具根本不會考慮接入Rome。

類似行為就像 —— 為什么Next.js?不原生支持Vite？當(dāng)然，別人會說這都是技術(shù)上的考慮，與生意無關(guān)。

總結(jié)

Rome的開發(fā)進(jìn)度誠如他的名字一樣 —— 羅馬不是一天建成的。

在前端領(lǐng)域迅猛發(fā)展，并隱隱有壟斷之勢的今天，要實(shí)現(xiàn)Rome宏大的愿景并取得足夠的市場份額并不容易。

你覺得Rome的前景如何呢？

參考資料

[1]Rome v10:https://rome.tools/blog/2022/11/08/rome-10.html。

[2]Rome Tools公司:https://rome.tools/blog/announcing-rome-tools-inc/。

[3]官方文檔:https://docs.rome.tools/guides/getting-started/。