耗時(shí)一年半才出第一版,這個(gè)工具會(huì)一統(tǒng)前端么?
大家好,我卡頌。
前端領(lǐng)域從不缺少熱點(diǎn),基本每過半年,就會(huì)出現(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ū)別?未來他會(huì)一統(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í)成本高
對(duì)于項(xiàng)目中常用的一些工具,比如:
代碼格式化工具:Prettier、dprint
lint工具:ESLint、StyleLint
測(cè)試工具:Vitest、jest
編譯器:babel、SWC
打包工具:webpack、vite、rollup
要熟練使用他們并不容易,因?yàn)椋?br>
需要了解不同工具如何配置
需要考慮如何將這些工具整合到項(xiàng)目中
最終,項(xiàng)目中往往充斥著各種各樣的配置文件。以至于復(fù)雜的項(xiàng)目中通常有個(gè)特殊的職位 —— 「webpack配置工程師」。
各種配置文件
很多腳手架工具(比如create-react-app)就是為了解決這個(gè)問題而生,但他們的缺陷也很明顯。
他們僅僅提供了膠水層隔離了這些工具的復(fù)雜度,但如果有個(gè)性化需求時(shí)開發(fā)者還是得直面這些問題。
而對(duì)于Rome驅(qū)動(dòng)的項(xiàng)目,只會(huì)有一個(gè)rome.json配置文件以及開箱即用的最佳實(shí)踐。
問題2:性能浪費(fèi)
前端工具鏈的很多工具都有訪問AST的需要,但很多時(shí)候他們是各自為戰(zhàn)的。
比如,babel處理代碼降級(jí)時(shí)會(huì)生成AST,eslint審查代碼時(shí)也會(huì)生成AST,這就造成了性能浪費(fèi)。
另一方面,前端工具用Rust重寫已然成為趨勢(shì)。
如果能將這些工具都用Rust實(shí)現(xiàn),并盡可能減少不必要的解析過程,就能顯著提高工具性能。
Rome的基本思路就是如此。根據(jù)小馬的計(jì)算,Rome格式化代碼的速度是Prettier的100倍以上:
benchmark
問題3:提示對(duì)開發(fā)者不友好
當(dāng)前很多前端工具是不同團(tuán)隊(duì)、不同個(gè)人開發(fā)的,所以在提示信息的準(zhǔn)確性、體驗(yàn)上各不相同。
Rome在「提示信息」上下了很多功夫,比如對(duì)于如下代碼:
function test(callback) {
try {
return callback();
} catch (e) {
console.log(e);
throw e;
}
return 20;
}
保存為a.js,執(zhí)行如下檢查命令:
npx rome check a.js
控制臺(tái)會(huì)輸出三段內(nèi)容。
第一段,告訴你return 20永遠(yuǎn)不會(huì)執(zhí)行:
后兩段會(huì)告訴你為什么不會(huì)執(zhí)行:
要不是因?yàn)閞eturn callback();
要不是因?yàn)閠hrow e;
相比eslint的提示信息,Rome的提示信息確實(shí)更友好。
未來,這樣友好的提示信息會(huì)出現(xiàn)在Rome工具鏈的每一環(huán),比如:
打包代碼的信息
lint信息
測(cè)試信息
Rome會(huì)一統(tǒng)前端么?
當(dāng)前,Rome只提供了linter(對(duì)標(biāo)eslint)、formatter(對(duì)標(biāo)prettier)兩個(gè)工具,可以通過如下命令體驗(yàn):
# 格式化
npx rome format <文件路徑>
# lint
npx rome check <文件路徑>
更詳盡的命令參考官方文檔[3]
如果未來Rome實(shí)現(xiàn)了他的目標(biāo),一定是對(duì)前端開發(fā)者很有吸引力的選擇。
但是,要實(shí)現(xiàn)這種大而全的解決方案并非一朝一夕就能完成的。
而在前端領(lǐng)域,新的技術(shù)、新的框架總是源源不斷的出現(xiàn)。
同為公司級(jí)的開源產(chǎn)品,vercel開發(fā)的next.js雖然選擇了與Rome不同的方向(以前端框架為切入點(diǎn)),但兩者的功能點(diǎn)一定有重合的一天。
從發(fā)展路徑看,對(duì)于next.js:
當(dāng)前:next.js依賴webpack打包
下一步:vercel投入到turbopack,next.js依賴turbopack打包
下一步:turbopack為了將自身速度優(yōu)勢(shì)發(fā)揮到極致,可能會(huì)用Rust重寫其他工具鏈工具
對(duì)于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的潛在競(jìng)爭(zhēng)者。
上面說的是未來Rome的成熟體與其他競(jìng)品的競(jìng)爭(zhēng)。而在當(dāng)前,作為linter與formatter,Rome的推廣也是阻力重重。
相較于eslint、prettier這樣帶著純正開源血統(tǒng)的開源項(xiàng)目,Rome宏大的愿景使得那些大用戶體量的工具根本不會(huì)考慮接入Rome。
類似行為就像 —— 為什么Next.js不原生支持Vite?當(dāng)然,別人會(huì)說這都是技術(shù)上的考慮,與生意無關(guān)。
總結(jié)
Rome的開發(fā)進(jìn)度誠(chéng)如他的名字一樣 —— 羅馬不是一天建成的。
在前端領(lǐng)域迅猛發(fā)展,并隱隱有壟斷之勢(shì)的今天,要實(shí)現(xiàn)Rome宏大的愿景并取得足夠的市場(chǎng)份額并不容易。
你覺得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/
作者:卡頌
歡迎關(guān)注微信公眾號(hào) :魔術(shù)師卡頌