Live data from Hacker News

Rome: A Linter for JavaScript and TypeScript

romefrontend.dev

81–90 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#81
post #35

Earlier quoted context omitted.

Hey there – I do mix the two of you up, but Babel is nothing to scoff at. I've used its internals in the past, and read a good chunk of its source code, so I think I've seen your blames all over. I'm quite appreciative of your past contributions! (and his) Reading your comment, it sounds like you expect some people might use Rome for some things (say, linting and compilation) and preexisting tools for others (say, fo…

Thanks! Yeah, it is, at least for a while since it will take a very long time to reach expected maturity. You can adopt as many or as little pieces as you want. The idea is that once you adopt one of the "tools", you can use the others and reuse the exact same configuration, and ideally you shouldn't even need to do anything else. ie. For linting we also do dependency verification. So you might need to configure Rome…

Thanks for this clarification. My first reaction to reading the project page was "damn a tool that takes doing everything to a whole new level". If it's adoptable piecemeal, there's a good chance that if it becomes popular I may actually get to work with it someday - but if it were an all or nothing proposal, in my current job the answer is likely to be nothing due to challenges integrating with other technologies we use and get value from.

Re: Rome: A Linter for JavaScript and TypeScript

#83

Earlier quoted context omitted.

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

Shifting ground from value add to required wasted time as ordered by leadership is an odd position.

It’s that kind of nonsense that incompetent people use to qualify prior bad decisions formed from insecurity at expense to everything else. It’s less clever than a person might think.

Re: Rome: A Linter for JavaScript and TypeScript

#84
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…

> standards for how things should be done

I cannot deal with these kind of statements and that's probably why I never use linters for my own projects. And yes, my code is good enough, a linter won't make it any better. It just blocks me time and time again and litters the codebase with: // eslint-disable-next-line

I never really understood why these tools are so popular and who really needs them. In the end it's all about the result of the code you've written, how easy it can be maintained and how good it works. No linter can help me with that.

Re: Rome: A Linter for JavaScript and TypeScript

#85
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…

sebmarkbage and sebmck are different people.

sebmarkbage is one of the architects of React and a TC39 member. He's known for the Fiber architecture, among other things.

sebmck/kittens wrote 6to5 as a teenager in Australia, eventually landed a job doing JS infra at Facebook, and now works at Discord. He's a founder Babel, Lerna, Yarn, and now Rome.

Re: Rome: A Linter for JavaScript and TypeScript

#86
post #77

Very happy to see that this is no longer a Facebook project, which I believe it was just a few months ago. I’d bet there’s a good story behind that. Let’s liberate React next?

Sebastian started it, and it followed him when he left:

https://romefrontend.dev/blog/2020/08/08/introducing-rome.ht...

Re: Rome: A Linter for JavaScript and TypeScript

#87

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

Closure's Achilles' heel is that it's written in Java. It's well-integrated into the stack at Google, but independent JS developers are often skeptical of tools that require more than `npm install`. It's been recently cross-compiler to JavaScript, so it is now available via npm.

Re: Rome: A Linter for JavaScript and TypeScript

#88
post #58
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 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 packages and 6 think-piece blog posts. It’s good stuff (I can speak for Next, dunno about Nuxt)

Re: Rome: A Linter for JavaScript and TypeScript

#89
post #38

Huge ambitious project and I hope it delivers. If anyone can lead this one to fruition is Sebastian. So this project is in good hands. Undeniably, it's technically ambitious to build all these pieces under a single umbrella. And then, convincing people who are honestly scared to touch their Webpack config to switch to a new tool might not be easier. But if Rome booms, it'll truly benefit the community.

> convincing people who are honestly scared to touch their Webpack config to switch to a new tool might not be easier. If someone can offer me a convincing alternative to webpack I will switch in a heartbeat.

Same, but the whole point is to switch you away from Webpack, Eslint, Prettier, Jest... I truly hate Webpack, but I do love Jest.

Basically, Rome will most likely need somewhat of a Typescript moment. Where it's just transitioning to the new normal for (many) JS projects.

Re: Rome: A Linter for JavaScript and TypeScript

#90
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…

> standards for how things should be done I cannot deal with these kind of statements and that's probably why I never use linters for my own projects. And yes, my code is good enough, a linter won't make it any better. It just blocks me time and time again and litters the codebase with: // eslint-disable-next-line I never really understood why these tools are so popular and who really needs them. In the end it's all…

> my code is good enough

Then you're perfect or your environment is perfect. Or you work alone?

Post reply on HN