Do all roads lead to Rome?

webdev javascript

We'll see what Rome is, how it fits into the JavaScript ecosystem, and my thoughts about it. Will Rome replace all the current tooling? Let's see.

What is Rome?

Rome is a full toolchain (can be used via CLI, VSCode extension, and in the future via API for testing purposes) that unifies the JavaScript and Typescript development: bundling, compiling, documentation generation, formatting, linting, minification, testing, type checking, etc. It tries to be a "one-in-all" solution, being able to do all these tasks under one CLI.

Perhaps you wonder if we can handle Webpack, Babel, Prettier, Jest, etc with this Rome CLI? The answer is NO... Rome implemented all these toolchain from scratch, without any dependency, using the same configuration file for everything.

The person behind this project is Sebastian McKenzie, the same author of Babel and Yarn, who has also worked on projects such as Prepack and React Native.

All tools lead to Rome
All tools lead to Rome

Rome is still in beta, and right now the current areas fully implemented are linting and formatting. The other areas are still in development.

Better performance

Current tools as webpack, TS, Babel, or ESlint, among others, run their own parser to generate an Abstract Syntax Tree (AST). After this, they manipulate and process their own AST.

When all these tasks become the only tool (Rome), we'll be able to reuse the AST for each task, parsing the files only once. Also, some processes will be simplified, for example: watching files, dependency verification, or integration with your editor.

Reusing the AST
Reusing the AST

Who benefits?

Only one configuration file

Right now we need to configure too many tools for a simple feature, for example, to work with absolute imports you need to configure ESLint, TS, and also webpack!

Config duplication
Config duplication

Instead, using the same tool (Rome) removes the duplicated configurations, so we'll only have one config file.

One config file for everything
One config file for everything

In addition, some tools configurations are currently depending on others, for example, Prettier has to be integrated with ESLint to avoid conflicting formatting. Often these tools integrations require adding a whole bunch of plugins to make them work together but, with Rome, we don't have the need to use any plugin since all the tools are perfectly integrated.

Who benefits?

Less dependencies

In the JavaScript ecosystem, we're used to work with many devDependencies for all the tools and their plugins: Jest, Babel, Prettier, webpack. Besides, each of them have their own dependencies.

With Rome, many of these devDependencies disappear, moreover Rome has zero dependencies.

Webpack vs Rome dependencies tree
Webpack vs Rome dependencies tree

So we have:

Friendly for beginners

As we've seen in the previous sections, Rome makes it much easier to start a project.

We feel more encouraged to start learning something new if we see that it has an easy start. In the last years starting JavaScript projects without frameworks was really complicated. Simplifying all this tooling will encourage many to learn and enter the world of JavaScript in a much more enjoyable way.

Picture of a woman learning JavaScript
Photo by Annie Spratt on Unsplash

In order to take the first steps in Rome, you can install it via yarn or npm, and then run npx rome init / yarn rome init to create the default .config/rome.rjson.

Finally, you can use every command of the CLI using rome [command], as rome check for linting and formatting a set of files, rome format to format a single file, rome start to start a daemon, etc. You can see all the available commands by running rome --help.

Do all roads lead to Rome? My thoughts about it

We started the article questioning about if Rome is going to replace all current toolchain. It's a question that will be answered over time, depending on the adoption of Rome within the community and the evolution of Rome and the current tools.

From my point of view, I think that in the short term the answer is "no". Although it replaces the functionality of those tools, that doesn't obsolete them. There are still a lot of projects that depend on them. However, in the long term I think the answer would be "yes". It may not be Rome, maybe another similar approach like Deno adopting a similar philosophy of having everything integrated.

In my opinion, the JavaScript ecosystem is too fragmented right now, you usually need to have a bunch of dependencies installed for most things. New projects like Rome or Deno, even though many people think that they're fragmenting even more the ecosystem, I think it's just the opposite. They're tools that aim to fix that fragmentation, and that's positive.

You may be wondering if one of the pieces doesn't fit 100% your needs and you still want to use your old tool. For example, you could prefer to continue using webpack as a compiler. The good thing about Rome is that if you only want to use one piece, you can. Thus, you can also use all of Rome's pieces except the compiler, to continue using webpack or another one.

Aral Roca (me) in philosophical mode
Aral Roca (me) in philosophical mode

Now it's your turn, what do you think about the future of JavaScript / TypeScript tooling?

References

Discuss on Dev.toDiscuss on TwitterEdit on GitHub

Subscribe to new posts! 📩

More...
HTML Streaming and DOM Diffing Algorithm

HTML Streaming and DOM Diffing Algorithm

GitHub action to publish your blog post to dev.to

GitHub action to publish your blog post to dev.to

Build Reactive Web Components with SSR

Build Reactive Web Components with SSR

SPA-Like Navigation Preserving Web Component State

SPA-Like Navigation Preserving Web Component State