There are very old reports saying the Rome build times are quite long, longer than a day even. Has this changed?
It's true. Unfortunately whichever road a project takes it will eventually lead to Rome.
The Rome Toolchain: A linter, compiler, bundler, and more
21–30 of 34 posts
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#22I wrote a little bit about Rome and my thoughts about it here:
https://aralroca.com/blog/do-all-roads-lead-to-rome
Hope it can be helpful to someone
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#23Not really important, but I love the new branding. IIRC, they were using a generic looking Spartan helmet before.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#24Are there any plans to port it to run on Deno?
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.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#25There are very old reports saying the Rome build times are quite long, longer than a day even. Has this changed?
It's true. Unfortunately whichever road a project takes it will eventually lead to Rome.
Do you mean that building the tool takes 1 day? LibreOffice compilation doesn't take as long, and LibreOffice is huge.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#26Are there any plans to port it to run on Deno?
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 +…
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...
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#27Earlier quoted context omitted.
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 +…
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 integrate…
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.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#28Earlier quoted context omitted.
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…
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.
You absolutely have this in the Java ecosystem also. Maven or Gradle + IDE plugins that need to be configured for most projects.
Python too, it's lessened by the fact that you can usually skips the build test, but there's often tox, pytest, setup.py, and coverage.py configuration in even simple projects.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#29Earlier quoted context omitted.
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 integrate…
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 buildi…
As an aside, Sapper in particular is probably not the future, as there’s been an unofficial announcement[1] that it will be replaced with file-based routing built in to the Svelte app template.
Re: The Rome Toolchain: A linter, compiler, bundler, and more
#30Earlier quoted context omitted.
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 integrate…
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 buildi…
That's totally fine and happy you have something you feel at home with, not everyone needs to be an early adopter and i would never advice people to jump on something when they think it might be a hype train but only when they see real advantage. The js ecosystem is famously evolving too fast to keep on top all the time anyways, we should also be allowed to relax and refine. By the way i think no one expects you to migrate your existing healthy projects to deno currently anyways. The current adoption cycle is at adopting js libraries like svelte to support js modules and deno, switching to deno for one shot scripts and new command line tools, developing replacements for basic nodejs libraries that dont make sense in deno or seem too archaic and building smaller internal tools and apps in deno and while doing so evolve the workflows, tools and best practices every step in the way. Especially importmap support and workflows need some evolving...