Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rome: An experimental JavaScript toolchain

romejs.dev

Post reply on HN
Print view View original

81–90 of 96 posts

Re: Rome: An experimental JavaScript toolchain

#81

Post by yohannparis »

sam_goody wrote: post #66
coolwhit wrote: post #61

Earlier quoted context omitted.

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

It does not handle CSS, JavaScript only

Re: Rome: An experimental JavaScript toolchain

#82

Post by ggambetta »

RcouF1uZ4gsC wrote: post #48

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.

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?

Re: Rome: An experimental JavaScript toolchain

#83

Post by a_humean »

dlbucci wrote: post #3

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?

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

Re: Rome: An experimental JavaScript toolchain

#84

Post by speedgoose »

petetnt wrote: post #51
speedgoose wrote: post #25

Earlier quoted context omitted.

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.

Re: Rome: An experimental JavaScript toolchain

#85

Post by ratww »

Raed667 wrote: post #41

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'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.

Re: Rome: An experimental JavaScript toolchain

#86

Post by ratww »

coolwhit wrote: post #75
sam_goody wrote: post #66

Earlier quoted context omitted.

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

Re: Rome: An experimental JavaScript toolchain

#87

Post by ratww »

sdegutis wrote: post #52
Raed667 wrote: post #41

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

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, an…

> 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

Re: Rome: An experimental JavaScript toolchain

#88

Post by [deleted] »

yohannparis wrote: post #81
sam_goody wrote: post #66

Earlier quoted context omitted.

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

It does not handle CSS, JavaScript only

[deleted]

Re: Rome: An experimental JavaScript toolchain

#89

Post by ratww »

lxe wrote: post #17
throwaway894345 wrote: post #5

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.

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 keepi…

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.

Re: Rome: An experimental JavaScript toolchain

#90

Post by ratww »

kevmo314 wrote: post #24
gear54rus wrote: post #11

Earlier quoted context omitted.

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?

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.

Post reply on HN