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 vertical. TS, ESlint, Prettier, Webpack, Babel.
Now, would it be nice if there were an underlying engine/server that all tools could use to share an AST without reparsing everything? Sure, I guess. Would it also be nice to have one tool that wraps the others, at least when you're getting started? Yes, though I think create-react-app has blazed that trail pretty well.
The thing is, all those tiny little details from Prettier and ESLint and Webpack really matter – Rome will take years to achieve the number of lints that ESLint has, and even more years for the community to agree on which ones matter. Similarly, every corner-case of prettifying will have to be considered anew, and every edge case of bundling rebuilt or reimagined.
I love to see a talented person take on something insanely ambitious, so I wish him luck and hope he proves me wrong. But if Rome succeeds, it'll be a big pain for a lot of people as they try to port everything over, and for the community as they grapple with dueling standards for how things should be done.
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 think a lot of people don't realize the sort of capabilities that they're missing out on by not having their tools work together, or sticking with old tooling that cannot innovate for legacy reasons (like Babel). I don't think it's harmful to the ecosystem to advocate for more consolidation, especially around tooling that not a lot of people either like to deal with, or have few maintainers in the first place.
I also think you have me (Sebastian McKenzie) confused with Sebastian Markbage from the React team.
Hey there – I do mix the two of you up, but Babel is nothing to scoff at. I've used its internals in the past, and read a good chunk of its source code, so I think I've seen your blames all over. I'm quite appreciative of your past contributions! (and his)
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?
Thanks! Yeah, it is, at least for a while since it will take a very long time to reach expected maturity. You can adopt as many or as little pieces as you want. The idea is that once you adopt one of the "tools", you can use the others and reuse the exact same configuration, and ideally you shouldn't even need to do anything else.
ie. For linting we also do dependency verification. So you might need to configure Rome if you put your dependencies on some weird non-standard place. Once we open bundling up, we'll already know how to resolve everything.
Each part should stand on it's own. It's not as if the linter we've released is worse, and the only selling point is that it's going to be part of a larger suite. It legitimately has features and separates itself from the alternatives. eg. extreme focus on useful error messages, powerful autofixes (that operate on an AST rather than insert strings like ESLint), proper caching for even better performance (ESLint doesn't offer a good solution here) etc.
Many are making the mistake in thinking that building Rome is just as time consuming and resource intensive as rewriting each of the tools it's meant to replace separately, it's not. Once we've validated the linter we've also validated the compiler (it's the same thing), our ability to watch files, analyze dependencies, integrate with your editor etc. Sharing so much fundamentally decreases the actual complexity of everything, not increases.
I think it's also important to note that I personally have written an extremely small amount of the implemented lint rules. Our API is just easier to use, and we've focused on setting up the tooling necessary to make writing them easy (although internally in our repo).
Check out https://github.com/romejs/rome/issues/341, https://github.com/romefrontend/rome/issues/20, and https://github.com/romefrontend/rome/issues/159, if you're interested in seeing how the progress was actually made in the implementation of those rules. The work was spread out over a really long time, and if given complete focus and proper coordination (I was not good at this and kind of let it be organized ad-hoc, which is actually how we got some amazing contributors), then it could have been completed in a fraction of the time.
There's been some overfocus on particular things like minimal configuration and the lack of extensibility but those are not hard requirements and will evolve over time, particularly as we get feedback and people demonstrate the requirements and restrictions they're under. The project understandably involves a lot of hubris, but I do believe that Rome isn't only valuable in aggregate and will have significant advantages even if you only decide to use one piece.
Thanks for this clarification. My first reaction to reading the project page was "damn a tool that takes doing everything to a whole new level". If it's adoptable piecemeal, there's a good chance that if it becomes popular I may actually get to work with it someday - but if it were an all or nothing proposal, in my current job the answer is likely to be nothing due to challenges integrating with other technologies we use and get value from.
I've also done some work on Prettier in the past, so I'm curious about some details there too.
1. Do you plan to build a wadler-based formatter, similar to prettier? Will it be as opinionated as prettier, or based on a pluggable architecture? (I'll admit that I have yet to conceive of a viable way to make the latter work well).
2. Have you considered (or already built) an incremental parsing server for tools like the formatter? For example, when I add a statement at the bottom of the document, will it reparse the whole document, or be smart enough to notice that a change has been made that can use cached results for most of the AST? (I'm not sure if this is feasible for JS, especially for parsers that require line/col info).
In any case, I'll be following your progress with great interest!
Welcome to web development, where change has been the only constant since—checks notes—the early 90s!
My way of coping with the appearance of yet another new-and-hyped thing, is to not complain and resist, nor to try to immediately learn the thing, but rather the much easier task of learning the why of the thing. Equipped with this knowledge, I can grok the JS ecosystem as a whole, and make better choices when it's time to choose a tool.
I do agree it's super exciting to see Sebastian McKenzie launch out with something new. I think I understand the why of this, and wish him every success!
Your comment says to me anxiety largely just at violating conventions of popularity. Your only hesitation is an appeal to authority. There is no consideration of merit or anything technical.
I read the anxiety as far less being about popularity than past trauma from the Javascript ecosystem and the whiplash it went through before it settled on the React/Vue/Typescript world we have today. When you go through that much change in the past, you really need a good argument to be convinced to try something new.
As a developer, I haven't had any qualms with ESLint, so I wouldn't really have any reason to pick up Rome. Now if the full tool set offers lots of things, then I might consider replacing my current Vue template / create-react-app, but that's a big step.
All of this to say, no, it's not an appeal to authority. It's sounds like a "I'm not sure I can imagine this being worth switching to because we have something that works and is stable now, and we haven't had a great track record with tooling churn in JS world". It's a value add question.
If that's really the problem you have to perform an honest self-assessment: are you spending more time and energy on tooling and framework drama than building/maintaing original products?
Its an important question to ask yourself as it directly indicates whether you are delivering or consuming business value. Developers will twist themselves into knots to falsely correlate those two things, but customers and end users absolutely don't care.
As much as this sentiment rings true, it's also a fairly useless one
Most people don't have jobs building/maintaining original products or delivering or consuming business value. Most people have jobs doing what someone else tells them. Business value just happens to be the byproduct of doing what is told. When this "someone else" finds this brand new tool, either they ignore it in favor of existing tooling which means you're never going to learn it which means you're left behind in a constantly changing ecosystem and then changing jobs becomes a massive pain because you're not familiar with said tool, or "someone else" loves it and you're forced to adopt it and your life is pain as you migrate ancient projects to try and please their whims
JS being in such constant flux means new companies making new products adopt the standards set by the current trends which means they will not hire you if your knowledge has gaps and if you're looking for new careers, you have to continually keep up. This is exhausting and a lot of people are, IMO rightfully so, frustrated
Shifting ground from value add to required wasted time as ordered by leadership is an odd position.
It’s that kind of nonsense that incompetent people use to qualify prior bad decisions formed from insecurity at expense to everything else. It’s less clever than a person might think.
You just repeated what I said, yeah? My whole point is not trying Rome is focusing on exactly that. Feels like we're going in circles here. The top level post you commented on is performing that exact assessment you just asked for and criticized as an appeal to popularity.
Even if it somehow manages to succeed at its mission and become the defacto toolchain for all of frontend, I feel its improvements over the status quo will be short lived, and over the long run having a monolithic toolchain dominate will prove to be a net-negative for the frontend tooling ecosystem.
Having a single defacto monolithic toolchain greatly raises the barrier to entry for new competing tools, as they'd no longer be able to just compete on the merits of doing any individual task better than its direct competition to gain adoption.
Having different single purpose tools that can people can pick and choose from independently of each other is a crucial part of what has enabled rapid innovation in the JS tooling ecosystem up till now, since it keeps implementation/switching costs for any individual tool as low as it can reasonably be for that specific use-case.
This comes at the cost of making it harder for any individual to keep up with all the latest innovations (as critics of the JS tooling ecosystem are often quick to point out), but projects like create-react-app have been fairly successful at addressing this through sourcing collective wisdom from the community to create a collection of best-in-class tools configured to work effectively together out of the box.
I can also totally emphasize that there are many low-hanging fruits in terms of efficiencies to be gained through unifying tooling to avoid wasted work and maintenance overhead, but I'm of the opinion that the gains in efficiency isn't going to be worth the cost in potential for stifled innovation, and that those efficiencies are better achieved through shared specs and shared low-level libraries that individual tools can choose to adopt if they become compelling enough.
I'm personally still going to be rooting for single purpose tools + curated collections over any monolithic toolchain.
With all that said, I for one would totally welcome something new in the formatting space to challenge prettier that decouples the line-length based autoformatting from the opinionated default styling presets.
JavaScript kind of always had this problem, and on the whole, it’s a good problem. Nobody forces new tools to become widely adopted. It happens because they improve enough stuff to convince us that switching is worth it.
When the web moved from jQuery to React, the details developers cared about changed. Opening modals got harder, but thats okay because React made so many other things better.
React is good enough to force us to adopt compilers for a language that doesn’t need them. When people complain about JavaScript on Hacker News, it’s usually about the build tools – and Rome has a shot at being an answer to that.
The web is more mature now, but that doesn’t mean the time for new tools is over.
sebmarkbage is one of the architects of React and a TC39 member. He's known for the Fiber architecture, among other things.
sebmck/kittens wrote 6to5 as a teenager in Australia, eventually landed a job doing JS infra at Facebook, and now works at Discord. He's a founder Babel, Lerna, Yarn, and now Rome.
Same, but I wouldn't say I'm happy with it. Everything's interdependant and that makes it such a pain to configure and maintain:
- Prettier has to be integrated with ESLint to avoid conflicting formatting and for good devX
- TS config interferes with ESLint config ("this file is not part of any project" or conflicting unused var warnings)
- Webpack has to be integrated with TS to compile down to JS
- ESLint, TS and Webpack all need configuring to know about absolute imports
If you throw babel into the mix, complexity just explodes. Thankfully it's feasible to have a stable config that "just works", but it can be quite the time sink. I wouldn't be against something that takes this pain away
Exactly. Let's say Eslint, TS, Prettier, Jest, and Webpack, are just standard for most projects I start.
The problem is, each little issue a developer has, often requires not just installing these, but then adding a whole bunch of plugins to make them work together. So whenever I start a project, my package.json is just already packed with a gazillion of devDependencies from @types/ to eslint and webpakc plugins.
This is the reason why I wrapped my Webpack config in its own package (same with Eslint), that way I pretty much only have a single dependency to add when starting or maintaining a project (and if a project has a very unique need, it can still modify the config generated by the package).
The package has a bunch of automated tests, so Dependabot checks for me if dependency updates are still compatible with the way I expect them to behave (and if a dependency needs to be swapped by another, I only need to do it in one place).
I cannot deal with these kind of statements and that's probably why I never use linters for my own projects. And yes, my code is good enough, a linter won't make it any better. It just blocks me time and time again and litters the codebase with: // eslint-disable-next-line
I never really understood why these tools are so popular and who really needs them. In the end it's all about the result of the code you've written, how easy it can be maintained and how good it works. No linter can help me with that.
I think the benefits of linting are similar to writing tests.
Initially the practice is detestable, especially if you've already developed some hard-fought coding chops without them. But after some time the practice itself influences your ability to write better code to start with, and successive tests become terser and more useful.
I think the same is true for linting. I found being involved in projects that enforce linting rules on commit to be insufferable, so I installed Prettier and configured it to format on save. Over time the auto-formatter did less because of the habits I was picking up.
I did have to confront the idea of being less precious and attached to my own coding-style, but frankly I still have pretty strong opinions despite having an automaton do my thinking for me in some of the projects I work on.
Of course, neither tests nor linting are a panacea, but so long as you give a hoot to start with you won't be able to avoid writing better code after using them.
> Over time the auto-formatter did less because of the habits I was picking up.
Indeed, making you more robot for "how things should be done".
Just one example: I like my code to be readable, and one of the things I apply for that is the use of white space. Between my functions/methods I have at least 3 lines of white space. It's a lie that this is not "how things should be done", and there is no way to tell prettier to accept that because it is meant to be opinionated. These tools have a place for some teams and junior devs, but I try to stay away from the ugly code it spits out.
Good point on teams, but I'm not convinced that linting is a great tool for juniors in the same way. Frustration is an instrument for learning, but adhering to linting rules forces that energy in the wrong direction for those still going through the basics.
On the point of being a robot, in what way are we not already "robots" by stubbornly sticking to what we think of as best? Are you not already a robot by limiting yourself to a narrow-range of what you consider "readable"?
I also find it annoying to occasionally lose white-space to Prettier. But I've learned my way around it: By either adding short comments or by decomposing single-lines into multiple ones, which ends up improving readability anyway.
Agreed. Creating a one-tool-to-rule-them-all is unlikely to help matters much.
To me, (and with the conversation restricted to applications, not websites or anything that is primarily a document for consumption), we should be going in exactly the opposite direction; reducing the number and scope of the extra tools we need to use.
We should be making bundlers unnecessary (javascript modules plus smart http 2 servers are one way, service workers are another), we should write code that targets the js that modern browsers understand so that babel is unnecessary as part of our main workflow and is only run if you want old-browser compatibility, we should look at folding the key parts of react into the DOM (firefox used to have something really not all that different from JSX, and the core functionality of react is pretty small - the DOM is a virtual DOM). Linting and source code formatting should primarily be part of your IDE/Editor workflow. Testing needs vary, and I want to be able to use the right framework for testing for the project without having to bring along all the other cruft.
What I loved about the web when I first started building apps for it was that I could start with a single file in an editor and grow from there. Making a change, pressing F5 and seeing the change immediately was so liberating compared to long compile times and complex build systems. With your code carefully written so as to fail fast, you could often see failures in the live application faster than my Java IDE would pick up a type error in Java code (anyone remember the white menu bar of doom?).
I think it's a great pity that we've taken one of the web platforms major strengths - fast iteration times, and added so much tooling. We used to scoff at the fake stackoverflow question where someone asked 'how to do addition in jquery', but the sheer quantity of tooling that is normally used for projects has put us in a similar position.
Honestly, I think your thinking is totally backwards.
Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community.
I feel the exact opposite: things like Rome (and Deno) are exactly the kind of projects that are needed in order to sort out a horribly fractured eco-system. I don't care who built them as long as they work well to solve the problems that so clearly exist.
> Wanting a project to be successful because of the person who started it is a terrible reason and has had (unsurprisingly) terrible results wherever I've seen it in the OSS community.
I somehow misinterpreted pipenv being an official python project. My usecase was pretty simple, I wanted a requirements.txt that only included the things I explicitly installed with perhaps a requirements-lock.txt with the actual list of things installed. :/
I didn’t even realize poetry existed until I talked to people who do python full time.
> 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 vertical. TS, ESlint, Prettier, Webpack, Babel.
Have we? I have 2019 projects I have worked on that dont use TypeScript and while I dont mind TypeScript I have a YAGNA attitude about it still. My coworkers seem to hate it despite never having used it. I think of TS as almost irrelevant if you can do JSHint but thats just me coming from Python 3 where type hinting is valid and doesnt require additional tooling to make it work.
Sadly I understand why JS syntax doesnt expand too much over the years and you need something like Babel.
But on the other hand if we stopped allowing legacy web clients we could probably push modern JS to more mature stages including type hinting (optional of course) as was done in Python 3.
You don't need to use any of these verticals - you can just write a .js file and serve it without any modifications, linting, etc.
But if you want to? Each vertical has a de-facto community standard at this point. If you want typechecking, it's TS. If you want formatting, it's Prettier. Etc.
And of course, nobody's captured 100% of any of these verticals - there are plenty of people who use Flow o Reason for typechecking, or "StandardJS" for formatting.
But a new person setting up a JS project can just install the community standards at this point and be fine (albeit bothered at configuring things, if they don't use c-r-a).
I don't see it this way; I see Rome as the Apple of front-end tooling. You use an opinionated service to do most of the work. No brainer!
If you want more configuration, build your own, and most people will do. But for the novice, people who do multiple new projects a year, or people who don't care about details, Rome will be great.
For homemade projects, I use CodeKit, and I think Rome will be the same without the friendly and refined GUI.
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 vertical. TS, ESlint, Prettier, Webpack, Babel.
Now, would it be nice if there were an underlying engine/server that all tools could use to share an AST without reparsing everything? Sure, I guess. Would it also be nice to have one tool that wraps the others, at least when you're getting started? Yes, though I think create-react-app has blazed that trail pretty well.
The thing is, all those tiny little details from Prettier and ESLint and Webpack really matter – Rome will take years to achieve the number of lints that ESLint has, and even more years for the community to agree on which ones matter. Similarly, every corner-case of prettifying will have to be considered anew, and every edge case of bundling rebuilt or reimagined.
I love to see a talented person take on something insanely ambitious, so I wish him luck and hope he proves me wrong. But if Rome succeeds, it'll be a big pain for a lot of people as they try to port everything over, and for the community as they grapple with dueling standards for how things should be done.