6 ms·

The Rome Toolchain: A linter, compiler, bundler, and more

64 points by 0xedb 6y ago

iddan 6y ago
The twitter discussion leading for the new domain and name of the project https://twitter.com/sebmck/status/1319870764435316736 https://twitter.com/sebmck/status/1319870764435316736
jadar 6y ago
I was confused for a moment, because this has the same name as a companion tool for Carthage. https://github.com/tmspzz/Rome https://github.com/tmspzz/Rome
zelly 6y ago
I started using webpack in 2015. It's still the tool I reach for when doing JS. It's not going anywhere.
- sabellito 6y ago
  Perhaps you could give parcel-bundler a shot.
pseudoramble 6y ago
When I try and check out their new page linked from here, I'm getting a certificate error. It looks like it's only issued for Netlify subdomains. Minor, but kinda annoying. One question I have about Rome is why it tries to take on the testing framework too. I really like the idea of it having all the build tooling together, but testing seems like a sort of separate thing. Other environments I've used let libraries fill the gaps for testing, including JS. Is there a big advantage to pulling it into Rome?
- ketzo 6y ago
  I guess the argument is that testing is very often another piece of the "developer experience" of a project, akin to linting or compilation. It makes some amount of sense to me, although I see where you're coming from.
  - pseudoramble 6y ago
    Right. I'm genuinely not trying to make a judgement on the choice - it's just not the choice I'm used to seeing, including in JS environments. So it seems like there must be some reasoning behind it. I suppose that's true! Practically speaking, it would be nice to have one testing framework to learn and use over-and-over again, but that's also kinda counter to what I'm used to in the JS world.
- acemarke 6y ago
  If you look at configuring a tool like Jest, there's a ton of "build tool" overlap, typically involving configuring Babel/TypeScript, parsing, path aliases, and so on. In particular, you usually have duplicate configuration for Jest and Webpack for all those things, but with completely different config file formats. Test runners also need to be able to iterate over files, run checks, and print diagnostics. Those all sound like things that Rome has the ability to do already, _and_ it's another tool that Rome could eliminate from a typical install. I'm not planning to switch to Rome any time soon, but I definitely understand the mindset involved in that approach.
  - Touche 6y ago
    This is a weird peculiarity of the JS ecosystem. The rest of programming ecosystems do not have dozens of tools all doing a build for you. When you run tests in C you do not use a special cli testing tool that also compiles your project... You just run cc on your test files and run it like everything else. Why JS prefers hiding the build I'll never understand.
    - acemarke 6y ago
      Not sure I agree with that statement. For example, I know that nUnit and jUnit are test runners for the .NET and Java ecosystems, and both of those are also runnable via the CLI. As for the JS ecosystem, it's definitely developed differently than other languages, because it deals with a very different set of constraints. See this article for background explanation (which also links to further reading) https://www.swyx.io/jobs-of-js-build-tools/ https://www.swyx.io/jobs-of-js-build-tools/
      - swyx 6y ago
        ayy tx for shoutout
    - ratww 6y ago
      Not really: dynamic languages (Python, Ruby, PHP) also have special cli testing tools just like JS, and that's where JS got inspiration from. What makes JS different is that it started having a compilation phase along the way, so both approaches hat to be combined.
sebastianmck 6y ago
Previous HN discussion: https://news.ycombinator.com/item?id=24094377 https://news.ycombinator.com/item?id=24094377 (first release) and https://news.ycombinator.com/item?id=22430682 https://news.ycombinator.com/item?id=22430682 (open source) Nothing has materially changed since the release announcement.
JohnBerea 6y ago
Are there any plans to port it to run on Deno?
- nathan_f77 6y ago
  Is anyone taking Deno seriously? I try to follow the latest trends in front-end development, and I haven't heard anything about Deno for a while. It didn't sound very attractive when I read about it, and I'm not excited about switching. I'll begrudgingly start using it if the community decides that it's better. Their dependency management idea also seems pretty bad to me, and it would be difficult to maintain. NPM + Snowpack [1] feels like a much better system. I think Node.js is probably going to stay the winner for now, but that might just be me. [1] https://www.snowpack.dev https://www.snowpack.dev
  - jFriedensreich 6y ago
    Everyone should take deno seriously, at this point imho it is pretty clear that nodejs is legacy and deno the future. It will not happen tomorrow of course as especially tooling and the nodejs compatibility layer has a long way to go but never dealing with node_modules again and a sound security model as well as web apis instead of custom nodejs ones is allready enough to make it killer, on top there is the integrated typescript runtime of course...
    - nathan_f77 6y ago
      Thanks for your comment, and I'm glad to see that you are excited about it! I personally won't be an early adopter and I don't want to do any of the work, but it would be great if lots of people get on board. I'm personally really happy with the current state of JS tooling, and I think node_modules are generally great and work fine. So I'm not too convinced about Rome or deno. I'm personally looking forward to building a new toy project with Svelte, Sapper, Tailwind CSS, and Snowpack (with TypeScript, Node.JS, and NPM.) This still feels like the future to me.
      - tobr 6y ago
ironmagma 6y ago
I tried learning this; there wasn't documentation on even the most basic of commands, `rome develop`, which failed. Sounds like a cool project, but the learning resources are really not there.
cjamesd 6y ago
Kind of goes without saying, but the flip side of having all of these tools under a single opinionated umbrella is that if any piece of it sucks, people are going to drop the whole toolchain. Hence this is a high risk project, especially because everything is being built from scratch.
- uranusjr 6y ago
  There’s a constantly swinging pendulum between “one tool to rule it all” and “bring your own tool.” Newcomers to an ecosystem get tired learning all the accumulated toolchain and want to build a thing to solve every problem. But it is always easier to build a tool that does only one thing, and gradually people replace each part of that one tool with better standalone tools, the ecosystem disintegrates into pieces. The cycle goes on. There’s no right or wrong, only nature.
gunnihinn 6y ago
There are very old reports saying the Rome build times are quite long, longer than a day even. Has this changed?
- catears 6y ago
  It's true. Unfortunately whichever road a project takes it will eventually lead to Rome.
  - oblio 6y ago
    Do you mean that building the tool takes 1 day? LibreOffice compilation doesn't take as long, and LibreOffice is huge.
- anonymous0 6y ago
  Rome wasn't built in one day
aralroca 6y ago
I wrote a little bit about Rome and my thoughts about it here: https://aralroca.com/blog/do-all-roads-lead-to-rome https://aralroca.com/blog/do-all-roads-lead-to-rome Hope it can be helpful to someone
skavi 6y ago
Not really important, but I love the new branding. IIRC, they were using a generic looking Spartan helmet before.
rendall 6y ago
I am very pleased with Webpack, but it definitely shows its roots as a specifically javascript bundler with other formats hacked on top. For instance, while one can have a `.css` file or `.html` file as an entry point, Webpack will nevertheless output a `.js` file with the same name for every entrypoint. I will be keeping my eye on Rome

64 points by 0xedb 6y ago

The twitter discussion leading for the new domain and name of the project https://twitter.com/sebmck/status/1319870764435316736 https://twitter.com/sebmck/status/1319870764435316736

jadar 6y ago

I was confused for a moment, because this has the same name as a companion tool for Carthage. https://github.com/tmspzz/Rome https://github.com/tmspzz/Rome

zelly 6y ago

I started using webpack in 2015. It's still the tool I reach for when doing JS. It's not going anywhere.

sabellito 6y ago
Perhaps you could give parcel-bundler a shot.

pseudoramble 6y ago

When I try and check out their new page linked from here, I'm getting a certificate error. It looks like it's only issued for Netlify subdomains. Minor, but kinda annoying. One question I have about Rome is why it tries to take on the testing framework too. I really like the idea of it having all the build tooling together, but testing seems like a sort of separate thing. Other environments I've used let libraries fill the gaps for testing, including JS. Is there a big advantage to pulling it into Rome?

ketzo 6y ago
I guess the argument is that testing is very often another piece of the "developer experience" of a project, akin to linting or compilation. It makes some amount of sense to me, although I see where you're coming from.
- pseudoramble 6y ago
  Right. I'm genuinely not trying to make a judgement on the choice - it's just not the choice I'm used to seeing, including in JS environments. So it seems like there must be some reasoning behind it. I suppose that's true! Practically speaking, it would be nice to have one testing framework to learn and use over-and-over again, but that's also kinda counter to what I'm used to in the JS world.
acemarke 6y ago
If you look at configuring a tool like Jest, there's a ton of "build tool" overlap, typically involving configuring Babel/TypeScript, parsing, path aliases, and so on. In particular, you usually have duplicate configuration for Jest and Webpack for all those things, but with completely different config file formats. Test runners also need to be able to iterate over files, run checks, and print diagnostics. Those all sound like things that Rome has the ability to do already, _and_ it's another tool that Rome could eliminate from a typical install. I'm not planning to switch to Rome any time soon, but I definitely understand the mindset involved in that approach.
- Touche 6y ago
  This is a weird peculiarity of the JS ecosystem. The rest of programming ecosystems do not have dozens of tools all doing a build for you. When you run tests in C you do not use a special cli testing tool that also compiles your project... You just run cc on your test files and run it like everything else. Why JS prefers hiding the build I'll never understand.
  - acemarke 6y ago
    Not sure I agree with that statement. For example, I know that nUnit and jUnit are test runners for the .NET and Java ecosystems, and both of those are also runnable via the CLI. As for the JS ecosystem, it's definitely developed differently than other languages, because it deals with a very different set of constraints. See this article for background explanation (which also links to further reading) https://www.swyx.io/jobs-of-js-build-tools/ https://www.swyx.io/jobs-of-js-build-tools/
    - swyx 6y ago
      ayy tx for shoutout
  - ratww 6y ago
    Not really: dynamic languages (Python, Ruby, PHP) also have special cli testing tools just like JS, and that's where JS got inspiration from. What makes JS different is that it started having a compilation phase along the way, so both approaches hat to be combined.

sebastianmck 6y ago

Previous HN discussion: https://news.ycombinator.com/item?id=24094377 https://news.ycombinator.com/item?id=24094377 (first release) and https://news.ycombinator.com/item?id=22430682 https://news.ycombinator.com/item?id=22430682 (open source) Nothing has materially changed since the release announcement.

JohnBerea 6y ago

Are there any plans to port it to run on Deno?

nathan_f77 6y ago
Is anyone taking Deno seriously? I try to follow the latest trends in front-end development, and I haven't heard anything about Deno for a while. It didn't sound very attractive when I read about it, and I'm not excited about switching. I'll begrudgingly start using it if the community decides that it's better. Their dependency management idea also seems pretty bad to me, and it would be difficult to maintain. NPM + Snowpack [1] feels like a much better system. I think Node.js is probably going to stay the winner for now, but that might just be me. [1] https://www.snowpack.dev https://www.snowpack.dev
- jFriedensreich 6y ago
  Everyone should take deno seriously, at this point imho it is pretty clear that nodejs is legacy and deno the future. It will not happen tomorrow of course as especially tooling and the nodejs compatibility layer has a long way to go but never dealing with node_modules again and a sound security model as well as web apis instead of custom nodejs ones is allready enough to make it killer, on top there is the integrated typescript runtime of course...
  - nathan_f77 6y ago
    Thanks for your comment, and I'm glad to see that you are excited about it! I personally won't be an early adopter and I don't want to do any of the work, but it would be great if lots of people get on board. I'm personally really happy with the current state of JS tooling, and I think node_modules are generally great and work fine. So I'm not too convinced about Rome or deno. I'm personally looking forward to building a new toy project with Svelte, Sapper, Tailwind CSS, and Snowpack (with TypeScript, Node.JS, and NPM.) This still feels like the future to me.
    - tobr 6y ago

ironmagma 6y ago

I tried learning this; there wasn't documentation on even the most basic of commands, `rome develop`, which failed. Sounds like a cool project, but the learning resources are really not there.

cjamesd 6y ago

Kind of goes without saying, but the flip side of having all of these tools under a single opinionated umbrella is that if any piece of it sucks, people are going to drop the whole toolchain. Hence this is a high risk project, especially because everything is being built from scratch.

uranusjr 6y ago
There’s a constantly swinging pendulum between “one tool to rule it all” and “bring your own tool.” Newcomers to an ecosystem get tired learning all the accumulated toolchain and want to build a thing to solve every problem. But it is always easier to build a tool that does only one thing, and gradually people replace each part of that one tool with better standalone tools, the ecosystem disintegrates into pieces. The cycle goes on. There’s no right or wrong, only nature.

gunnihinn 6y ago

There are very old reports saying the Rome build times are quite long, longer than a day even. Has this changed?

catears 6y ago
It's true. Unfortunately whichever road a project takes it will eventually lead to Rome.
- oblio 6y ago
  Do you mean that building the tool takes 1 day? LibreOffice compilation doesn't take as long, and LibreOffice is huge.
anonymous0 6y ago
Rome wasn't built in one day

aralroca 6y ago

I wrote a little bit about Rome and my thoughts about it here: https://aralroca.com/blog/do-all-roads-lead-to-rome https://aralroca.com/blog/do-all-roads-lead-to-rome Hope it can be helpful to someone

skavi 6y ago

Not really important, but I love the new branding. IIRC, they were using a generic looking Spartan helmet before.

rendall 6y ago

I am very pleased with Webpack, but it definitely shows its roots as a specifically javascript bundler with other formats hacked on top. For instance, while one can have a `.css` file or `.html` file as an entry point, Webpack will nevertheless output a `.js` file with the same name for every entrypoint. I will be keeping my eye on Rome