耗時一年半才出第一版,這個工具會一統前端么?
大家好,我卡頌。
前端領域從不缺少熱點,基本每過半年,就會出現新的工具。
在這樣快節奏的浪潮中,有個工具卻顯得格格不入,他就是Rome。
從名字中我們就能窺探出一絲端倪,看看別的工具:
- vite(法語中「快的」的意思)。
- turbopack(英語中「渦輪增壓器」的意思)。
再看看他 —— 寓意是「羅馬不是一天建成的」。
事實也如此,Rome團隊用時一年半終于上線了第一個穩定版本Rome v10[1]。
作為前端工具鏈工具,Rome?和那些我們耳熟能詳的工具(比如vite?、eslint?、CRA)有啥區別?未來他會一統前端么?
今天我們來聊聊這個話題。
Rome是什么
Rome?的創造者是前Babel團隊的「Sebastian McKenzie」,后文就叫他小馬吧。
21年5月?,小馬拿了2家風投450w刀的投資后成立了Rome Tools公司[2]。
這家公司的目標是:實現一站式前端工程化解決方案,以替代現有的各種前端工具。
在小馬看來,當前的前端工程化解決方案存在很多問題,比如:?
問題1:工具太多,學習成本高
對于項目中常用的一些工具,比如:
- 代碼格式化工具:Prettier、dprint。
- lint工具:ESLint、StyleLint。
- 測試工具:Vitest、jest。
- 編譯器:babel、SWC。
- 打包工具:webpack、vite、rollup。
要熟練使用他們并不容易,因為:
- 需要了解不同工具如何配置。
- 需要考慮如何將這些工具整合到項目中。
最終,項目中往往充斥著各種各樣的配置文件。以至于復雜的項目中通常有個特殊的職位 —— 「webpack配置工程師」。
各種配置文件
很多腳手架工具(比如create-react-app)就是為了解決這個問題而生,但他們的缺陷也很明顯。
他們僅僅提供了膠水層隔離了這些工具的復雜度,但如果有個性化需求時開發者還是得直面這些問題。
而對于Rome驅動的項目,只會有一個rome.json配置文件以及開箱即用的最佳實踐。
問題2:性能浪費
前端工具鏈的很多工具都有訪問AST的需要,但很多時候他們是各自為戰的。
比如,babel處理代碼降級時會生成AST,eslint審查代碼時也會生成AST,這就造成了性能浪費。
另一方面,前端工具用Rust重寫已然成為趨勢。
如果能將這些工具都用Rust實現,并盡可能減少不必要的解析過程,就能顯著提高工具性能。
Rome的基本思路就是如此。根據小馬的計算,Rome格式化代碼的速度是Prettier的100倍以上:
benchmark
問題3:提示對開發者不友好
當前很多前端工具是不同團隊、不同個人開發的,所以在提示信息的準確性、體驗上各不相同。
??Rome?
?在「提示信息」上下了很多功夫,比如對于如下代碼:
保存為a.js,執行如下檢查命令:
控制臺會輸出三段內容。
第一段,告訴你return 20永遠不會執行:
后兩段會告訴你為什么不會執行:
- 要不是因為return callback():
- 要不是因為throw e。
相比eslint的提示信息,Rome的提示信息確實更友好。
未來,這樣友好的提示信息會出現在Rome工具鏈的每一環,比如:
- 打包代碼的信息
- lint信息
- 測試信息
Rome會一統前端么?
當前,Rome只提供了linter(對標eslint)、formatter(對標prettier)兩個工具,可以通過如下命令體驗:
更詳盡的命令參考官方文檔[3]
如果未來Rome實現了他的目標,一定是對前端開發者很有吸引力的選擇。
但是,要實現這種大而全的解決方案并非一朝一夕就能完成的。
而在前端領域,新的技術、新的框架總是源源不斷的出現。
同為公司級的開源產品,vercel?開發的next.js?雖然選擇了與Rome不同的方向(以前端框架為切入點),但兩者的功能點一定有重合的一天。
從發展路徑看,對于next.js:
- 當前:next.js依賴webpack打包。
- 下一步:vercel投入到turbopack,next.js依賴turbopack打包。
- 下一步:turbopack為了將自身速度優勢發揮到極致,可能會用Rust重寫其他工具鏈工具。
對于Rome:
- 當前:主打linter、formatter。
- 下一步:開發其他工具鏈工具。
當兩個產品有了功能相同的工具時,即使Rome?開發體驗更好(假設),但早已深度耦合在Next.js技術棧的開發者要想切換底層工具鏈工具是不可能的。
不僅是vercel?,Vue?團隊、Remix?團隊等都是Rome的潛在競爭者。
上面說的是未來Rome?的成熟體與其他競品的競爭。而在當前,作為linter?與formatter?,Rome的推廣也是阻力重重。
相較于eslint?、prettier?這樣帶著純正開源血統的開源項目,Rome?宏大的愿景使得那些大用戶體量的工具根本不會考慮接入Rome。
類似行為就像 —— 為什么Next.js?不原生支持Vite?當然,別人會說這都是技術上的考慮,與生意無關。
總結
Rome的開發進度誠如他的名字一樣 —— 羅馬不是一天建成的。
在前端領域迅猛發展,并隱隱有壟斷之勢的今天,要實現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/。