Rome: An experimental JavaScript toolchain | Hacker News Reader

Rome: An experimental JavaScript toolchain

romejs.dev

129 pointspcr91030392 comments

Previous discussion: https://news.ycombinator.com/item?id=22430682

Same jokes too.

Maybe this is intuitive to JS devs, but what are the advantages of "zero third-party dependencies" and "being a comprehensive tool for the processing of anything JS related" or any of the other selling points of Rome? It seems like an impressive project, but it's not obvious to me what its actual benefits are.

I think the implicit benefit to doing it this way is that it will just work because there are likely few options and all combinations of those options will likely be tested and supported by the developers.

It's not intuitive to me as a JS dev too... Are you guys gonna re-implement typescript for example? Where does 'no deps' line get drawn?

Echoing this sentiment. I think there's value in consolidating parts of the JS toolchain as there's a lot of variability there with how you can adjust your build system and pick your flavor of the week linter/formatter/bundler/etc. I'm not sure how 'no deps' is a a feature though, aside from (potentially) less packages to download during development.

Same, I don't mind having an alternative to webpack, but competing against prettier is going to be an uphill battle.

I don't know. The whole point of using Prettier is that you're delegating your style choices to someone else.

And there were already some (very small) breaking changes between Prettier v1 and v2.

Changing from Prettier to something else doesn't sound like that big of a change, as long as Rome's formatter is not too ugly or changes are too drastic.

It's more of a network effect though that keeps me using prettier. These days I end up using prettier in codebases so my code looks like everyone else's, not just so it's self-consistent. It just makes it easier to read.

You're right though if Rome has a formatter that looks nice I suppose I wouldn't care, but at that point it's sort of like why not just use prettier?

> You're right though if Rome has a formatter that looks nice I suppose I wouldn't care

Well, then I guess it wouldn't be an "uphill battle" :)

"No dependencies" isn't quite accurate. There are a couple, and they are TypeScript and related packages: https://github.com/facebookexperimental/rome/tree/master/nod...

But everything else is on track to be reimplemented within Rome.

Note that the TypeScript dependency is not used at runtime. It's only used to type check the Rome source code.

Source https://news.ycombinator.com/item?id=22431169

It's a common story: monolith or microservices? Linux do one thing well or holistic cohesion? Mega repo or many small ones? There are pros and cons. Nothing in the universe is currently more fragile than a modern js toolchain tho.

Starting a new JS project these days can be a huge hurdle for many users because they have to manually set up all the compilation/linting/testing/formatting etc infrastructure, each of which have multiple possible libraries, versions, and non-trivial configurations. You could spend a week configuring webpack alone to get code splitting, css compilation, etc to work. Projects like create-react-app and next.js have helped remove some of this fatigue, and you can see by their adoption just how much of an impact this has. Seems like Rome should be similarly beneficial without being inherently tied to an application framework like create-react-app or next.js – the challenge will be avoiding a confusing mess of 1000 configuration options to fine-tune each subsystem.

This is exactly it for me. Just setting up my project took well over a week (not like I couldn't do anything before that week was over, but getting everything how I wanted it was very non-trivial). Granted, a lot of it was because I was new to TypeScript, but I also got into a bunch of version hell trying to get TypeScript/Prettier/ESLint/VSCode to all work together on my machine because there were a bunch of version incompatibilities when tslint was essentially deprecated in favor of eslint for TypeScript.

This is all expanded on in the README:

> No external dependencies. This allows us to develop faster and provide a more cohesive experience by integrating internal libraries more tightly and sharing concepts and abstractions. There always exist opportunities to have a better experience by having something purpose-built.

See more of the technical reasons behind Rome here: https://github.com/facebookexperimental/rome#technical

Less dependencies = less layers of indirection and complexity making feature addition, iteration, testing, and debugging easier and much faster. If you need to change or tweak a function that a dependency usually covers, it's much easier to do if you're dealing with one single codebase (using same style, idioms, build structure, etc...). You don't have to worry about pinning or unpinning dependency versions and keeping track of their security issue, patches, and minor/major bumps.

This is the big one for me. Just looking at the Create-React-App dependencies I can count 17 dependencies dedicated to interconnecting Webpack/Babel/ESLint/Jest/Terser/Typescript.

Plus there's the cost of having plugin-infrastructure and/or maintaining a public API inside the six tools themselves. Plus all of them have dependency on a parser.

Having it all in one single tool will tremendously reduce the amount of code necessary.

Have you used npm before? It's a complete mess.

Prerequisites: npm

Greatly reduce the likelihood of supply-chain attacks.

Dependency bloat is a problem in all popular programming language ecosystems, but has proven to be statistically a bigger deal in the JS ecosystem than in others.

Real problems this causes:

1. security surface area. Running npm audit in many large projects is going to give you scary results. And that's just the known advisories.

2. 3rd-party support. How many of the 1000+ packages you've ended up pulling into your node_modules will continue to be actively maintained throughout the life of your project, what stability pains will dead subdependencies cause, and what will the long-term maintenance cost of rooting them out (and finding equivalent replacements) be? Will it cause forced deprecation of features in your app?

So with all the above, low-dependency/no-dependency projects are attractive. Many go to extreme and repeat the old mistakes of NiH. Rome seems to me to be this extreme kneejerk (and liable to some serious lock-in).

The sensible thing here is moderation: just choose dependencies carefully.

I like the idea of simplifying the tool chain, but I'm curious how flexible Rome will be in terms of settings/customization.

Like, if it "replaces webpack", am I locked into Rome's idea of what an "optimal bundler config" looks like? If I need more from a bundler, do I have to completely replace Rome with the "old" toolchain? How extendible is Rome on its own?

I'm wondering if it will have something like CRA's "eject" that allows you to override the defaults, without having to replace entire portions of it.

> what are the advantages of "zero third-party dependencies"

Dependencies are great for solving problems you are not willing or capable of solving. They are great when you need them, but most software includes dependencies that aren't needed or even directly requested. That is bloat. For example the Angular JS framework requests nearly 1100 NPM dependencies. That is a tremendous amount of code for an insignificant value add.

For example when webpack 4 came out, A bunch of loaders broke, but other ones depended on it, and I had to spend a full week trying out different numbers after my packages in my packages.json (the dependency file for node projects) until everything worked again. And then 2 weeks later shit started breaking again when we needed to add another library.

Is this meant to replace Webpack + some list of plugins, does this get added to Webpack, or is this meant to go somewhere else entirely in the JS toolchain?

If this replaces Webpack, can someone please list a combination of popular plugins that this compares to. (Or even a few lists - would it replace Grunt + something?)

If not, can you tell me what other software this compares to, so that I can better understand it?

I am sure that I am not the only one who has some familiarity, but doesn't live in the system. Having a point of comparison would be extremely helpful.

The scope is even broader! Webpack is just a bundler. Rome is a bundler, linter, test runner, typescript compiler, and formatter. The proper comparison would be Webpack + ESLint + Jest + TSC + Prettier.

Thank you!

So, this is a bundler with built in plugins?

Is there is a way to add Babel etc, that I would have used with Webpack? Does it handle CSS?

And why would I prefer this over that chain (simpler to set up? Trust in Facebook over the people at js.foundation?)

The standard stack is unnecessarily complex and very difficult to security-audit. By not having any third-party dependencies, you don't need to trust thousands of individual developers to not have their NPM accounts compromised or to push something with a subtle security bug.

The selling point is that you don't need plugins at all. Rome is the entire toolchain in one tool. For example, you don't need to add Babel because Rome handles transpilation.

The question is - will Rome perform as well as all the tools it intends to replace. Can it be a better Babel than Babel is? (There's a good chance it could since the creator of Rome is the creator of Babel)

I would bet on it performing better too, since Webpack/Babel/ESLint/TSC/Terser/Prettier all have to parse/process/pretty-print the code, using Javascript as the intermediate representation between each tool. That's very wasteful.

With a unified tool you can use a single AST. Or even better: an intermediate representation. You only need to parse and pretty-print once.

It does not handle CSS, JavaScript only

I've been using fuse-box for a while, and am not sure I could be much happier. It's a bundler with big dreams, but mostly it's just really fast and the devs are responsive.

I have been following the progress of this project on Twitter for months. However I'm very skeptical to see this project used in a production app.

Re-implementing the entire JS toolchain for a modern SPA is a HUGE task, just checkout CRA dependencies : https://github.com/facebook/create-react-app/blob/master/pac...

It looks like Rome is a Facebook Open Source project, so there's reasons to believe a huge amount of resources is being put into it (probably the only way something like this is feasible).

(This is not a statement either pro or against FB, just a neutral one :)

It was mostly built by one guy at least until very recently and not during company time from what I hear for the most part. Perhaps it was, but either way it doesn’t have huge firepower as of yet.

Then again, even React itself only has a small core team, same with lots of Facebook projects. I think they should hire more aggressively and become more of a tech-driven company (they should be fighting for the web platform too a lot stronger).

> so there's reasons to believe a huge amount of resources is being put into it

The commit log shows that everything is committed by one person: https://github.com/facebookexperimental/rome/commits/master

I've seen it happen enough times where a significant amount of complexity can be removed altogether by addressing a problem at the root in a fundamentally different way. Thousands upon thousands of lines of code can just disappear[1]. I have seen firsthand how complex Babel is, and I'm also skeptical about anything that claims it could replace Babel. But I also looked at Rome's parser and it's not trivially small, and the README says it's made by the same people who made Babel. So I have good reason to believe this is probably a serious restart with justifiable properties.

[1] https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

> But I also looked at Rome's parser and it's not trivially small, and the README says it's made by the same people who made Babel

It is the same parser used in Babel, but modified to be faster and more user-friendly [1]. This is probably how the author got so much done in just a few years.

[1] https://twitter.com/sebmck/status/1136426174265978882

yes this is a very ambitious project but with enough time and resources it can serve the JavaScript a great service.

I believe in Sebastian. He can do it.

It's not that crazy when you look at the dependencies themselves:

- 17 of them are just to connect the core dependencies with each other. Having one single tool means you can drop those.

- 12 are "plugins" for different parsers/linters. I believe third-party parsers/linters is something that will keep existing in Rome.

- 11 are plugins, loaders and other tools that provide additional functionality to the core tools, such as loading raw files, loading raw HTML, handling case sensitive paths, inject hot-loading code. They range from trivial to complex (webpack-dev-server). We don't know how much of that functionality Rome will have built-in, so those might not be going away.

- 1 is a wrapper around the core tools, 1 contains polyfill and 7 are "util" packages that do just one thing each (taking a cursory look, most of those are already implemented in Rome).

- 5 are the core tools are Rome intend to replace: Webpack, Babel, ESlint, Terser and Jest. The most complex of the four was built by the Rome author himself.

- There's also Typescript and PostCSS but those are third-party dependencies, and AFAIK Rome doesn't intend to replace those).

When you take into account that the first four are tools built around parsers it makes A LOT of sense to put them all into a single tool, and there's a lot of overlapping functionality.

The hardest part is not really replacing the core four tools, but rather replacing the whole ecosystem that exists around ESLint, Webpack and Babel. But if the AST format is the same, there's a chance that a compatibility layer would be enough to even use ESLint/Babel plugins in Rome!

Sure you might lose a bit of edge cases and features (Webpack has a lot of things), but it will be entirely reasonable to start a new project with Rome when it's ready without losing much.

Replacing those tools in an existing project is probably very hard, though: there's a bunch of Webpack non-standard features that cause vendor lock-in, but as someone who migrated large Webpack projects to use Rollup or Parcel, it's not as hard as it seems IME.

But yeah it's hard.

I feel it is driven by Facebook security. Third party NPMs or "poisoning the watering hole" attack is feasible against big tech giants. Some cryptocurrency projects have already been hit by this.

The premise is attractive, but the challenge will be keeping up with a rapidly-changing ecosystem. The advantage of letting Webpack and Babel be separate, having both as singular community focal-points for their respective tasks, and having both be extensible via plugins (the TypeScript team can work independently from the Babel team, for example), is that the leg-work of adding new JS features, parsing new syntaxes, keeping up with the spec, etc. can be distributed in the most efficient way possible. A single team trying to do everything in-house, duplicating the work of all of the above communities, will have a very hard time keeping up. But I wish them luck.

I don't know if want this or if I really just want create-react-app for things that aren't react. A lot of tools do things Good Enough (which everyone disagrees on and will always fragment the ecosystem). But I do loathe setting up all the plumbing from scratch.

Quasar framework / cli is nice for vue.

A lot of JS projects now have create-$X-app. Not all are as well thought out as CRA but its a good start.

Rome seems fine but I find this approach to be a bit more interesting https://github.com/swc-project/swc — though Rome seems potentially broader in scope.

> Rome has a logo of an ancient Greek spartan helmet. It's not very relevant since it's not Roman, but it looks cooler than a Galea.

It's OK. JavaScript has very little to do with Java, so it fits.

Never mind that they're wrong, this isn't even a proper spartan helmet.

Zero third party dependencies or how to market the [NIH /reinventing the wheel syndrome] (https://en.m.wikipedia.org/wiki/Not_invented_here)

This is a really exciting idea to me, but this website is pretty anemic (guessing it's a work in progress?). Kinda surprising to me, given the 7K stars on github. Maybe it should be submitted when it's a little more filled in?

AFAIK, the high number of stars are because of who the author is.

Personally, considering how ambitious the project is, I was hoping they would go just a bit more ambitious and cover type checking as well (rather than just transpile out the syntax), otherwise we still need to install Typescript/flow and run their parsers independently from rome.

As a person who’s getting ready to drop a project: what about the docs site is “anemic”? It’s using docusaurus which is pretty snazzy as far as docs sites go. Do you mean the amount of content on the site?

Content. It had like a single page, which didn't give me too much information...

Its because of who the primary author of the project is, and so it immediately has a fair bit of credibility.

What does it compile JavaScript to? WebAssembly or machine code or something else?

Probably ES6 to ES5

Oh right a transpiler.

It's perfectly valid to call that a compiler.

Yeah I know it’s just extra useful context to add that it’s a transpiler. Otherwise you’re left confused about what it’s compiling to.

TypeScript and JSX to JavaScript.

What a very 'interesting' name for a project that is an integrated and consistent Javascript toolchain that aims to replace existing third party libraries and tools. It may be too early to see if this is a good idea or not but who knows, at least no one can say that this was built in a day.

Does it work with Deno? I'd love to burn down the existing JS world and move to a better one.

An alternative lightweight and fast JavaScript buildchain using Snowpack: https://github.com/garage11/vuepack-demo

It says "No Third Party Dependencies" but 95% of the code is written in TypeScript, so it isn't even JavaScript and the entire thing is built on top of one big dependency.

Would not be a problem if it didn't sell itself as "zero third party dependencies" while being built on top of one that is not even JavaScript... Might as well built the tool in any other language that would have been better for the task.

typescript is just a language, how is that a dependency? by that logic, nothing is dependency free.

But the end users can't run the typescript, whereas they can run javascript directly. So, an external tool is required by the developer.

A similar comparison would be shipping a program to end users, saying that 'no dependencies required', but instead of giving them a binary to run, you hand them a c++ file. I think everyone would agree that a C++ compiler is clearly a required dependency in that case.

Would you say the same about a single-header library for C++?

> an external tool is required by the developer

Yes, that tool is Rome. They are re-implementing the TypeScript compiler, just like everything else

Nobody says a C file has a "dependency" because you have to compile it.

Like that point is fair, but almost no C code has no dependencies. Like just a basic application that returns 0 and nothing else from main will need to link to crt0. https://en.wikipedia.org/wiki/Crt0

However, you can compile C code as a bin file (just instructions). More common in the embedded world or you need to bootstrap an OS ect...

Static binaries do not have any dependency, and those that are not static typically depend on libc etc., regardless of the language being C, JavaScript (the browser) or anything else. So we don't count them as "dependencies".

But my point above was to counter the "C compiler is a dependency" claim. Nobody counts that way when discussing running programs, and that was my point.

There are dependencies to build a program, and dependencies to run it. Sure a static binary can run without any run time dependencies if written to run on bare metal (without an OS). Although, you could go further down that rabbit hole and say the hardware is a dependency. (better start writing stuff in VHDL and Verilog /s)

Both types of dependencies do come up. However, most people don't consider language dependencies. However, if you for instances need to port your code to a lot systems such dependencies can suddenly be very important. Especially if you have to do the porting. So to say: "Nobody says a C file has a "dependency" because you have to compile it." is a bit disingenuous. There is a lot of C code that require features only available in certain compilers. At which point that code now depends on that compiler.

However, JS seems to have problem with too many dependencies, at times these dependencies can be trivial that is makes someone ask why...

Building Rome does require typescript. It's a devDependency. Using Rome (ie, the `rome` command that gets built) does not.

"No dependencies" seems accurate to me, since it refers to use of the built product, which is what will presumably be used in the future when you can `npm install rome`.

I'm comparing it to JavaScript, which you can simply run in the browser or in NodeJS without requiring anything else but your code. You can't just use TypeScript, you have to compile it to JavaScript before, as the runtime is still either the browser or NodeJS.

The TypeScript compiler and the various @types NPM packages are dependencies. Node and NPM are also dependencies since this project will not execute without them.

What this project means by no dependencies is that there is nothing external pulled into the compiled JavaScript.

From the Getting Started Guide:

> Then, navigate into it and build rome:

> cd rome; ./scripts/build-release dist

Be aware that this command might take a long time to complete. After all, Rome wasn't built in a day.

I know they said in the GitHub readme, but I still chuckled. Good chance I'm just losing my mind.

LOL!

It actually only takes a couple of minutes, with ANSI fancy progress bars and everything

There's a non-zero probability that the only reason they chose to call this Rome is so they could make this joke :)

I mean, there's precedent... remember Nero Burning ROM?

I mean, clarifying that it's in-progress is important.

After all, Rome wasn't built in a day.

Cue the jokes.

And when you do something with your project they didn't anticipate their response would be: 'When in Rome...'.

clap clap clap

For more information about the name, the README elaborates:

> Rome gets its name from proverbs such as "All Roads Lead to Rome", "Rome wasn't built in a day" and "When in Rome, do as the Romans do". This refers to the expansive scope and the desire for conformity across the project. It started as a joke at the office.

https://github.com/facebookexperimental/rome#history

Who is going to maintain all of this in a few months or years when Facebook has moved on?

If they end up using Rome internally that should be a good sign that it will be supported for years to come. React has been very well maintained for the past 5+ years.

I don't know. I don't think they stopped testing, but their open-source javascript testing framework jest has been unmaintained for a little while.

Jest had a new release 5 days ago, so "a little while" is quite literally a very short while.

My bad. It feels unmaintained though.

Isn't this true of all open source projects?

When it's many smaller projects, the workload can be shared and it's easier to replace a dead component.

The primary dependency I'd like to get rid of when developing JS would be the big corporations. Between my compiler, my linter and my frontend tool, there's quite an empire of evil.

Reply on news.ycombinator.com