Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rome: A Linter for JavaScript and TypeScript

romefrontend.dev

Post reply on HN
Print view View original

21–30 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#21

Post by wildpeaks »

rattray wrote: 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…

I removed Babel from my toolchains a while ago, so it's even shorter: TS, ESlint, Prettier, Webpack.

Re: Rome: A Linter for JavaScript and TypeScript

#22

Post by tln »

Konohamaru wrote: post #9

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.

Re: Rome: A Linter for JavaScript and TypeScript

#23

Post by ironmagma »

Konohamaru wrote: post #9

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.

And what’s wrong with the early days? Great things were accomplished back then.

Re: Rome: A Linter for JavaScript and TypeScript

#24

Post by austincheney »

rattray wrote: 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…

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.

Re: Rome: A Linter for JavaScript and TypeScript

#25

Post by Jarred »

rattray wrote: 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…

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.

Re: Rome: A Linter for JavaScript and TypeScript

#26

Post by streptomycin »

sebastianmck wrote: post #19
rattray wrote: 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 thin…

Eventually one of you needs to bite the bullet and change your name!

Re: Rome: A Linter for JavaScript and TypeScript

#27

Post by wildpeaks »

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 generate node bundles or only browser bundles

- can it split chunks

- do you still get TS intellisense in VSCode

- can it be used with Rust and/or Webassembly

Re: Rome: A Linter for JavaScript and TypeScript

#28

Post by sebastianmck »

wildpeaks wrote: post #27

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.

Re: Rome: A Linter for JavaScript and TypeScript

#29

Post by wolfgang42 »

rubber_duck wrote: post #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)

The TypeScript compiler API[1] is beta, underdocumented, and not really designed to support use-cases other than working with an abstract AST. It’s OK for transpiling, but would be a bit awkward for writing a linter and not at all suitable for a formatter.

As an example of the sort of problems you might run into with the API in its current state, trying to parse and then pretty-print code can cause comments to vanish[2] under certain circumstances. This is fine for transpiling, but is a major issue when you’re trying to prettify and overwrite the original source file.

[1] https://github.com/Microsoft/TypeScript/wiki/Using-the-Compi... [2] https://github.com/microsoft/TypeScript/issues/39620

Re: Rome: A Linter for JavaScript and TypeScript

#30

Post by constexpr »

rubber_duck wrote: post #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)

I think the odds are pretty good. The TypeScript compiler's performance is not optimal: https://twitter.com/evanwallace/status/1275945317045657602. Microsoft's TypeScript team has a lot of priorities and other things likely take precedence over performance work.

Also it's pretty trivial to build a faster compiler if you don't have to worry about type checking. You can still have type checking with a bundler that ignores types by running the official TypeScript type checker in parallel with your bundler.

Post reply on HN