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

71–80 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#71

Post by austincheney »

adjkant wrote: post #52
austincheney wrote: post #24

Earlier quoted context omitted.

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…

> from the Javascript ecosystem

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.

Re: Rome: A Linter for JavaScript and TypeScript

#73

Post by no_wizard »

I feel like Google could have had this with their Closure Compiler/Sheets/Templates/Library but they never dedicated any resources to making the APIs more ergonomic and they’ve been historically poorly documented as well, not to mention for one reason or another the Compiler doesn’t do automatic dependency traversal and because the APIs are not not intuitive and well documented they lost mindshare.

Like many great Google projects it just never got fully realized, which is a shame :(

Re: Rome: A Linter for JavaScript and TypeScript

#74

Post by tonyhb »

esperent wrote: post #67
throwaway894345 wrote: post #10

Earlier quoted context omitted.

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.

Agree. I went as far as regressing to `watchexec` to re-run esbuild and cargo build on any changes. Esbuild is near instant compared to anything else.

Re: Rome: A Linter for JavaScript and TypeScript

#75

Post by capableweb »

sebastianmck wrote: post #56
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…

TypeScript is a frontend language. "Frontend" is the category of languages we plan on supporting. It doesn't say anything about your usage of those languages. Where you run the code does not matter.

Could you expand on why you think TypeScript is a "front-end" language? I was under the impression that it just compiles to Javascript and while Javascript used to be a front-end language, it's nowadays bravely used for backend projects as well, for some reason.

Re: Rome: A Linter for JavaScript and TypeScript

#76

Post by aniforprez »

austincheney wrote: post #71
adjkant wrote: post #52

Earlier quoted context omitted.

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…

> from the Javascript ecosystem 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 th…

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

Re: Rome: A Linter for JavaScript and TypeScript

#78

Post by atom_arranger »

rk06 wrote: post #70
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

esbuild does not type check. TypeScript type checks and then emits code. Better performance can be achieved by just stripping types and emitting code.

It would be great to improve the performance of type checking, but that’s more complicated.

Some project are trying, the Deno maintainers have asserted that TypeScript should be rewritten in Rust for better performance. swc is trying to do that - https://github.com/swc-project/swc/issues/571

Re: Rome: A Linter for JavaScript and TypeScript

#79

Post by Vinnl »

Vinnl wrote: post #2

Sebastian keeps mentioning how all these different kind of tools could re-use the same infrastructure for the things they all do, but... It's still not quite clear to me what benefit that brings to me as a non-contributor? I can see how it could be beneficial if the entire ecosystem would rally around the same tools and then be able to move faster, but given that that has not yet happened... Why would I use this to l…

Thanks for the answers everyone. Just wanted to point out this comment by Sebastian that also perfectly explains it: https://news.ycombinator.com/item?id=24096744

(And it would be good to put something to that extent prominently on the website, if it isn't yet.)

Post reply on HN