31–40 of 140 posts
Ugh. I cannot stand names based on ancient things or myths. They remind me of the early days of programming when systems were named Neptune, Iapetos, or Cronus in order to make themselves sound bigger or larger than life.
I like the name. It evokes "all roads lead to Rome" Although "Borg" might be more accurate.
A few questions on top of my head when I consider changing the toolchain: - does it handle images imports - does it handle scss imports - if not, does it require css-in-js (and if so which one) - does it handle shaders imports (and other arbitrary dependencies that need custom processing to get embedded in the bundle) - does it generate SRI hashes for stylesheets and scripts - can it generate web workers - can it gen…
It's a linter so you don't need to ask any of those questions. Future usage as a bundler isn't dependent on any decision to use it as a linter.
Ugh. I cannot stand names based on ancient things or myths. They remind me of the early days of programming when systems were named Neptune, Iapetos, or Cronus in order to make themselves sound bigger or larger than life.
There's something that scares me about Rome: it's lack of plugins. I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins. How will Rome support compile time transformations like graphql.macro or typecheck.macro? Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks…
I spoke in this post about how rushing into a plugin system hurt the longevity of Babel and it's ability to innovate. We aren't going to make the same mistake again. Rome will likely eventually have a plugin system, but what that would look like isn't clear. This is the first release and until there's some actual usage, there's no real way to realistically predict what sort of things people will feel is missing. You…
As someone who works on libraries that don't use JSX, and therefore have to rely on compiler and linter plugins to get support (tagged template literals in my case) I worry that React's dominance will mean that it gets a place in Rome, while other systems are locked out, which only increases React's dominance.
Would you consider an internal plugin system as a first step, where plugins have to be part of the codebase, but intentionally get a restricted API surface? This would allow you to try out and refactor the plugin API over time before committing to it publicly.
I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
The ecosystem is already fragmented and dueling. When it says it replaces those tools it means it aims to replace the functionality of those tools, not make them obsolete. Rome being successful doesn't mean eliminating those tools, it's providing something valuable and giving people an option. If it's not for you then that's okay. Rome is early and is still evolving, including possible areas for extensibility. I thin…
Reading your comment, it sounds like you expect some people might use Rome for some things (say, linting and compilation) and preexisting tools for others (say, formatting and bundling). Is that your intent?
I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
I feel so torn on this project. On the one hand, I want to root for sebmarkbage, who has done so much for the field. On the other, as someone who used to do some "JS platform" work at a tech company, I really don't want Rome to catch on. Yet Another Standard is really painful for the ecosystem, and while it's obnoxious that you need so many tools, at least we've finally settled (mostly) on good answers for each verti…
Huge ambitious project and I hope it delivers. If anyone can lead this one to fruition is Sebastian. So this project is in good hands. Undeniably, it's technically ambitious to build all these pieces under a single umbrella. And then, convincing people who are honestly scared to touch their Webpack config to switch to a new tool might not be easier. But if Rome booms, it'll truly benefit the community.
If someone can offer me a convincing alternative to webpack I will switch in a heartbeat.
Ugh. I cannot stand names based on ancient things or myths. They remind me of the early days of programming when systems were named Neptune, Iapetos, or Cronus in order to make themselves sound bigger or larger than life.
Rome is the current capital of Italy... not a mythical or ancient thing.