Live data from Hacker News

Rome: A Linter for JavaScript and TypeScript

romefrontend.dev

11–20 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#11
post #6

the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo: - ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go bi…

I wrote about something related as well: Disintegrated Development Environments — How Did We Get Here?

https://amasad.me/disintegrated

Re: Rome: A Linter for JavaScript and TypeScript

#12
Why start this from scratch ? Why not build on top of TypeScript ?

I get the single pass rationale but isn't it possible to integrate a bundler into TypeScript compiler ?

I'm just wondering because Microsoft has a decently sized team of paid engineers working on TS for years now - what are the odds an OSS project outperforms them at implementing their own language (which they also evolve with every release)

Re: Rome: A Linter for JavaScript and TypeScript

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

Re: Rome: A Linter for JavaScript and TypeScript

#14
post #6

the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo: - ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go bi…

After spending way too much time debugging issues with frontend tooling, I am all on board for this glorious monotool future. We’ve definitely gotten some progress out of the massively micropackage approach that Webpack/Babel/etc use, but these days it really feels like we’re passing a complexity limit and we need a new approach. The fact that CRA will refuse to startup if you have another version of Babel installed anywhere in the tree, is a pretty good clue that the current approach isn’t scaling.

Re: Rome: A Linter for JavaScript and TypeScript

#15
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 possible.

[1] https://github.com/vedantroy/typecheck.macro

Re: Rome: A Linter for JavaScript and TypeScript

#17
post #6

the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo: - ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go bi…

Don't forget https://github.com/swc-project/swc

Re: Rome: A Linter for JavaScript and TypeScript

#18
post #15

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…

They are not the same thing. Despite not supporting plugins, I think you can definitely expect Rome to support some form of macros, thought it might look different from the existing API in babel.

Re: Rome: A Linter for JavaScript and TypeScript

#19
post #13

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

Re: Rome: A Linter for JavaScript and TypeScript

#20
post #15

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 can always supplement your project with multiple linters if you feel like it is currently a blocker.

Post reply on HN