4 ms·

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-implement

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/packages/react-scripts/package.json https://github.com/facebook/create-react-app/blob/master/pac...

miohtama 7y ago
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.
godot 7y ago
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 :)
- nwienert 7y ago
  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).
- ipsum2 7y ago
  > 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 https://github.com/facebookexperimental/rome/commits/master
sdegutis 7y ago
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_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
- ratww 7y ago
  > 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 https://twitter.com/sebmck/status/1136426174265978882
msoad 7y ago
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.
ratww 7y ago
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.

miohtama 7y ago

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.

godot 7y ago

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 :)

nwienert 7y ago
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).
ipsum2 7y ago
> 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 https://github.com/facebookexperimental/rome/commits/master

sdegutis 7y ago

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_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

ratww 7y ago
> 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 https://twitter.com/sebmck/status/1136426174265978882

msoad 7y ago

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.

ratww 7y ago

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.