社区精选｜耗时一年半才出第一版，这个工具会一统前端么？

今天小编为大家带来的是社区作者 卡颂 的文章，让我们今天来聊聊Rome。

前言

---

大家好，我卡颂。

前端领域从不缺少热点，基本每过半年，就会出现新的工具。

在这样快节奏的浪潮中，有个工具却显得格格不入，他就是Rome。

从名字中我们就能窥探出一丝端倪，看看别的工具：

• vite（法语中快的的意思）

• turbopack（英语中涡轮增压器的意思），

再看看他 —— 寓意是罗马不是一天建成的。

事实也如此，Rome团队用时一年半终于上线了第一个稳定版本Rome v10https://link.segmentfault.com/?enc=F6o2Np0lgjT5YSoiiweXyQ%3D%3D.00Ie92zQXB8cFnftUQv0fiz8hkLbdPQ3GkdYaVMZ6Xs8kmd%2F4AnYpgW8PQkuyQpL。

作为前端工具链工具，Rome和那些我们耳熟能详的工具（比如vite、eslint、CRA）有啥区别？未来他会一统前端么？

今天我们来聊聊这个话题。

Rome 是什么

---




Rome 的创造者是前 Babel 团队的Sebastian McKenzie，后文就叫他小马吧。

21 年 5 月，小马拿了 2 家风投 450w 刀的投资后成立了 Rome Tools 公司https://link.segmentfault.com/?enc=z0uhe%2FT1ifHqNnpKpTKK%2Bg%3D%3D.o53NXOnOz7QLjjKtZJ%2FsbmWL10aFiP0f33OjMnh9Lc0na1qBi0iieEt6XkjpPYDMOAec8VGFN1UuMvNf7tAbcw%3D%3D

这家公司的目标是：实现一站式前端工程化解决方案，以替代现有的各种前端工具。

在小马看来，当前的前端工程化解决方案存在很多问题，比如：

问题 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 倍以上：

问题 3:提示对开发者不友好

当前很多前端工具是不同团队、不同个人开发的，所以在提示信息的准确性、体验上各不相同。




Rome在提示信息上下了很多功夫，比如对于如下代码：

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

  return 20;
}

保存为a.js，执行如下检查命令：

npx rome check a.js 

控制台会输出三段内容。

第一段，告诉你return 20永远不会执行：

后两段会告诉你为什么不会执行：

• 要不是因为return callback();

• 要不是因为throw e;

相比eslint的提示信息，Rome的提示信息确实更友好。

未来，这样友好的提示信息会出现在Rome工具链的每一环，比如：

• 打包代码的信息

• lint 信息
• 测试信息

Rome 会一统前端么？

---

当前，Rome只提供了linter（对标eslint）、formatter（对标prettier）两个工具，可以通过如下命令体验：

# 格式化
npx rome format <文件路径>

# lint
npx rome check <文件路径>

更详尽的命令参考官方文档 https://link.segmentfault.com/?enc=erdvm0cT28PDp2mDao8%2FAw%3D%3D.Nfu375ZnyVrC6FtCIUERr4VGb2FBV1L%2FtdfDzw2q8OzDP3WHdG271SQtpUnCWMrn

如果未来 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的前景如何呢？

---

点击左下角阅读原文，到 SegmentFault 思否社区 和文章作者展开更多互动和交流，“公众号后台“回复“ 入群 ”即可加入我们的技术交流群，收获更多的技术文章~

- END -

关注公众号：拾黑（shiheibook）了解更多

赞助链接：

关注数据与安全，洞悉企业级服务市场：https://www.ijiandao.com/
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/