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

101–110 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#101

Post by rattray »

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…

Yep, that's exactly where I was coming from. Thanks.

Re: Rome: A Linter for JavaScript and TypeScript

#102

Post by davidy123 »

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.

I want to somehow make the point, which seems to be somewhat out of fashion this season (it was a focus a few years ago), that one of the features of Javascript is that it's universal/isomorphic. And that the average computer (and even smartphone) is very powerful, so if storage is abstracted, the distinction blurs. To me, this means features like browser based tools, which are gradually becoming more user friendly, don't really need a "server," except perhaps as a way to coordinate and for long term storage. Eventually, I think a non technical user should be able to create content that contains open-ended dynamic formatting and distributed data based views, without a round trip to a server. If they want to dip into arbitrary Javascript, maybe just re-using a module, fine. Ultimately, the same code might be used in the browser as that in a development process. Current markdown tools and notebooks are headed in this direction. However, trying to use something like mdx-js shows we are far from reasonable bundle sizes when taking this approach. One-tool-per-application might yield the small bundle sizes and dynamism for this goal. Wondering if Rome has this goal in mind. Thanks!

Re: Rome: A Linter for JavaScript and TypeScript

#103

Post by williamdclt »

wildpeaks wrote: post #21
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.

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

Re: Rome: A Linter for JavaScript and TypeScript

#104

Post by giancarlostoro »

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…

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

Re: Rome: A Linter for JavaScript and TypeScript

#105

Post by draw_down »

I like this idea, I’m tired of configuring tools that I use together to know about one another. I don’t need most of the notional power that arrangement supposedly can offer, and configuring these tools has only gotten more bewildering. Tired of screwing around with an endless array of plugins. Many of us build react apps, I think it’s worth having a toolchain that caters to that.

I care a lot more about dev experience and speed than “one tool to do one job”. The “job” is to handle the code I’m working with in a way that isn’t as frustrating as our current tools.

Re: Rome: A Linter for JavaScript and TypeScript

#106

Post by williamdclt »

jitl wrote: post #88
kbenson wrote: post #58

Earlier quoted context omitted.

I think maybe what's missing is one tool which the "one thing" it does well is put all the other tools together seamlessly and make sure they work right. My guess is that's what an IDE is supposed to do (I say "my guess" because I've always done my development in Vim). I just know that every time I revisit any JS front-end stuff, I end up punting and just manually adding script/stylesheet includes for Vue and Bootstr…

There are some claims to this thrown recently: * create-react-app serves as a very basic frontend template for a React project. It eliminates worrying about Babel, webpack, polyfills, etc * next.js / nuxt.js solve both front-end and backend for React / Vue. Likewise they package webpack, Babel, typescript, etc, and also help with bundle splitting, routing, and server-side rendering that used to take 30 different pack…

> create-react-app serves as a very basic frontend template for a React project. It eliminates worrying about [...]

Until you need to do something that CRA doesn't do. Then you have to learn about babel/webpack/whatever AND how to do get CRA to play ball with it. I'm still on the fence on whether CRA and its leaky abstractions is better than a boilerplate with working config files exposed

Re: Rome: A Linter for JavaScript and TypeScript

#108

Post by rmthw »

rubber_duck wrote: post #54
wolfgang42 wrote: post #29

Earlier quoted context omitted.

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…

I get that - but since TS is also OSS you can fork and upstream, still sounds like less work than writing everything from scratch.

Why?

TS and Rome architectural goals are completely incompatible.

Writing a transpiler is not complicated at all, especially for someone who has written Babel in the past.

On the other hand, if you familiarise yourself with both TS's gigantic codebase and with Rome's goals, you'll quickly see that modifying TS would be much vaster undertaking than writing it from scratch.

Also if Rome were just an also-ran to replace ESLint/Webpack/Babel/etc, it would be ok to have a less-than-ideal starting point, but it's actually trying to do things differently: better error messages, recoverable parser errors, more fixable linter messages, being faster.

This is the exact case of something that should be written from scratch (or at least use something that makes it possible) rather than building on some another technology with completely incompatible goals.

Another example? It took several years for Webpack to achieve tree-shaking that was as good as Rollup first versions, even with more maintainers, more sponsorship and a lot of time. Why? Because Webpack's architecture was completely different.

Re: Rome: A Linter for JavaScript and TypeScript

#109

Post by swimmingly »

I just don't see the use case for RomeJS and I'm not sure people will want to wait several years for this project to mature. esbuild seems to hit the sweet spot for ESNext/TS/JSX/bundling - it's 100 times faster than current tooling and works today with with next to no configuration.

Re: Rome: A Linter for JavaScript and TypeScript

#110

Post by rattray »

giancarlostoro wrote: post #104
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…

> 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 havin…

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

Post reply on HN