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

61–70 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#61

Post by lewisl9029 »

lewisl9029 wrote: post #60
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…

Definitely share this sentiment. 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 n…

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.

Specifically motivated by this popular issue: https://github.com/prettier/prettier/issues/5814

:)

Re: Rome: A Linter for JavaScript and TypeScript

#62

Post by dmitriid »

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

It's a good thing. It should get the defaults right first before rushing into plugins. Webpack had everything delegated to plugins without a single sane default for years which only contributed to its complexity. As thebiggest example: it had a several-thousand word article on consistent caching that used three different plugins for three or four years before that became default behaviour in version 5.

I, for one, welcome a future of build tools without plugins.

Re: Rome: A Linter for JavaScript and TypeScript

#63

Post by toohotatopic »

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

Isn't this the reason why it is called Rome? In JavaScript history, we are past Babel (and the Greek city states) and a centralized tooling will allow for an unprecedented language economy?

Constantinople and Moscow are waiting, as well as Venice and London. A plugin system that wants to incorporate everything will risk having to maintain Byzantine diplomatic relations. On the other hand, restricting the plugin system to its core will create a local powerhouse that will utterly fail to adapt once new ventures become available.

I am waiting for the TypeScript / JavaScript split.

Re: Rome: A Linter for JavaScript and TypeScript

#64

Post by tbeseda »

smhmd wrote: post #41

I liked the old logo[0] better. [0]: https://raw.githubusercontent.com/romefrontend/rome/1d583050... [1]: https://raw.githubusercontent.com/romefrontend/rome/main/ass...

That helmet is Greek. It was a placeholder. There's a pretty good GH issue[0] for creating the new one.

[0]: https://github.com/romefrontend/rome/issues/1

Re: Rome: A Linter for JavaScript and TypeScript

#65

Post by jtwaleson »

amasad wrote: post #11
swyx wrote: 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

Wow! I've been trying to put my thoughts about this into a blog post, but it would have ended up (or will end up) almost exactly like yours (except I didn't know about "Worse is Better"). Great to see someone with such similar ideas!

Re: Rome: A Linter for JavaScript and TypeScript

#66

Post by _greim_ »

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…

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!

Re: Rome: A Linter for JavaScript and TypeScript

#67

Post by esperent »

throwaway894345 wrote: post #10
swyx wrote: 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…

Man, the performance benchmarks that esbuild publishes are pretty remarkable. I know it's common to cherry-pick favorable benchmarks, but even if these are misleading by two orders of magnitude esbuild would be best in class.

I also found them unbelievable so I did some quick tests with a couple of large projects that I'm working on, currently using Rollup. From these, I'd say their benchmarks are completely accurate.

Re: Rome: A Linter for JavaScript and TypeScript

#68

Post by esperent »

elondaits wrote: post #33
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.

Rome is the current capital of Italy... not a mythical or ancient thing.

However, it is a little bit weird to name a programming tool after a country's capital city. Are we gonna get the London linter next? Or the Washington DC web framework?

Re: Rome: A Linter for JavaScript and TypeScript

#69

Post by no_wizard »

novaleaf wrote: post #53
iRomain wrote: post #39

Why a focus on frontend only? I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend. If you got to do it, do it all the way! I can already see the GH issues, “sorry, this is a backend use case”. So now my tooling would end up being more complex with the addition of another tool since it will never support all my use cases. Seemed promising but this alone makes me question its ut…

I just last week found out about https://rushstack.io/ you might like it.

I think this has a brighter future than lerna if you are managing a monorepo They’re betting big on PNPM being a strong long term bet.

They also just recently released Heft which is the rushstack repo build/lint/dev-server stack.

It’s a promising project

Re: Rome: A Linter for JavaScript and TypeScript

#70

Post by rk06 »

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)

>what are the odds an OSS project outperforms them at implementing their own language?

A lot more than you imagine. Esbuild can already transpile 100x faster than typescript.(Note: esbuild does not typecheck).

If they use similar technique as esbuild, they can easily surpass typescript compiler in all functional areas

Post reply on HN