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

131–140 of 140 posts

Re: Rome: A Linter for JavaScript and TypeScript

#131

Post by rmthw »

rubber_duck wrote: post #116
rmthw wrote: post #108

Earlier quoted context omitted.

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…

But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack. Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. What use case of TS would you exclude to arrive at simpler code base ? Writing a transpiler that ignores type checks is probably simple but also qui…

> Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend.

I'm not suggesting at all that they're incompetent, but you seem to be...

Typescript's goal was not extensibility in the way it would be needed for Rome to use it as its base. There is nothing wrong with that.

Also, it's not "incompetence" to write a codebase that is hard to extend or modify to do something in a completely different way. It's just a difference of priorities.

Of course it would be better to only have easily-modifiable codebases in the world, but this is not possible. Teams might have other conflicting goals.

Don't fool yourself into thinking that a good codebase has every single positive attribute in the world just because it's a good codebase, or because its authors are good coders.

Webpack was harder to modify than creating Rollup from scratch, GCC was harder to modify than it was to create LLVM from scratch, Linux is immeasurably harder to modify than Minix if you want it to do things it was not . But it doesn't mean that those codebases are worse or better.

--

> What use case of TS would you exclude to arrive at simpler code base ?

Why would I want to exclude any use case from Typescript? I actually mentioned Rome's raison d'être is to have more things than other transpilers.

It's a matter of architecture and early choices, of how the parser/ast/pretty-printer were implemented. Not really a matter of features we can remove.

Re: Rome: A Linter for JavaScript and TypeScript

#132

Post by rmthw »

rubber_duck wrote: post #130
brundolf wrote: post #128

Earlier quoted context omitted.

It's entirely possible then to use tsc as a "global" typechecker for the purposes of your dev workflow, without making it a part of your build process (unless you're doing CI, in which case it could still be a separate, preliminary pass that doesn't have to be bound up in the actual build stage). All I'm saying is, especially for a project like Rome that has so many other irons in the fire, I think it's a fully legit…

But what's the value proposition of this solution then ? If I need to run separate processes anyway what's the benefit over running webpack with TS and a fork checker ?

Better error messages, an error-recoverable parser, faster speed, consolidation into a single tool, additional ability to lint/pretty-print/minify/test instead of just transpiling and bundling, having zero dependencies, having a smaller codebase.

Maybe those things are not important for you, but they are for the Rome author and for many people in the community.

Also with brundolf's solution you can run the TSC typechecker (but not the transpiler/emitter) and Rome in parallel, making good use of modern multi-core processors. With Webpack+TSC you'll have to typecheck, transpile and bundle all in series. This might be very significant.

Re: Rome: A Linter for JavaScript and TypeScript

#133

Post by rmthw »

rubber_duck wrote: post #116
rmthw wrote: post #108

Earlier quoted context omitted.

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…

But you're basically trying to superset the TS compiler. If this doesn't cover TS typechecking then it fails on it's promise of a single pass compiler stack. Are you suggesting that TS team is so incompetent or legacy burdened that their codebase is impossible to extend. What use case of TS would you exclude to arrive at simpler code base ? Writing a transpiler that ignores type checks is probably simple but also qui…

Also, the ball has been in Typescript's court for a while to provide a fast, easy to use typecheck-only API that receives an AST and can be used by other tools that already have parsers.

If that existed, it would allow Typescript it to be embeddable, and Rome could use that.

People have been asking for it for half a decade.

Re: Rome: A Linter for JavaScript and TypeScript

#134

Post by brundolf »

rubber_duck wrote: post #130
brundolf wrote: post #128

Earlier quoted context omitted.

It's entirely possible then to use tsc as a "global" typechecker for the purposes of your dev workflow, without making it a part of your build process (unless you're doing CI, in which case it could still be a separate, preliminary pass that doesn't have to be bound up in the actual build stage). All I'm saying is, especially for a project like Rome that has so many other irons in the fire, I think it's a fully legit…

But what's the value proposition of this solution then ? If I need to run separate processes anyway what's the benefit over running webpack with TS and a fork checker ?

There are lots of use-cases for producing a working build that doesn't necessarily pass type-checks. Active development, for one. I often find myself hacking on something and actively ignoring certain TypeScript errors that I know won't cause breakage, until I'm at a point where I want to start polishing things up. During this time I may need to test out the functioning-if-unsafe iterations, and I don't want to be blocked by errors that I plan to clean up later. Another case is if you're building a clean checkout; if you already know there are no type errors, there's no need to check again. The two are simply separate, if related, concerns.

Re: Rome: A Linter for JavaScript and TypeScript

#135

Post by adjkant »

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…

You just repeated what I said, yeah? My whole point is not trying Rome is focusing on exactly that. Feels like we're going in circles here. The top level post you commented on is performing that exact assessment you just asked for and criticized as an appeal to popularity.

Re: Rome: A Linter for JavaScript and TypeScript

#136

Post by adjkant »

schwartzworld wrote: post #126
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…

it's weird that you think of TS as being a settled-on part of the stack.

Developer surveys show it's one of the most agreed-upon tools in the JS stack from users:

https://2019.stateofjs.com/javascript-flavors/#javascript_fl...

Re: Rome: A Linter for JavaScript and TypeScript

#137

Post by ARussell »

namelosw wrote: post #49

Is there any chance that Rome can be based on Deno in the future? It seems to me Deno has built with browser-like environments in mind, thus the environment would be more unified. Node.js is pretty much a different beast. If we want to have an ambitious project like Rome, I would love to have it based on an ambitious foundation.

I asked this question, as well, and the answer I got is that Deno already does these things.

Re: Rome: A Linter for JavaScript and TypeScript

#138

Post by wecryopen »

schwartzworld wrote: post #125
Aeolun wrote: post #38

Earlier quoted context omitted.

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

Parcel is pretty amazing

agree 100%. love how it requires no configuration.

Re: Rome: A Linter for JavaScript and TypeScript

#139

Post by jitl »

williamdclt wrote: post #106
jitl wrote: post #88

Earlier quoted context omitted.

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

But, CRA comes with a button that turns it into a boilerplate with working config files.

Re: Rome: A Linter for JavaScript and TypeScript

#140

Post by kybernetikos »

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…

Agreed. Creating a one-tool-to-rule-them-all is unlikely to help matters much.

To me, (and with the conversation restricted to applications, not websites or anything that is primarily a document for consumption), we should be going in exactly the opposite direction; reducing the number and scope of the extra tools we need to use.

We should be making bundlers unnecessary (javascript modules plus smart http 2 servers are one way, service workers are another), we should write code that targets the js that modern browsers understand so that babel is unnecessary as part of our main workflow and is only run if you want old-browser compatibility, we should look at folding the key parts of react into the DOM (firefox used to have something really not all that different from JSX, and the core functionality of react is pretty small - the DOM is a virtual DOM). Linting and source code formatting should primarily be part of your IDE/Editor workflow. Testing needs vary, and I want to be able to use the right framework for testing for the project without having to bring along all the other cruft.

What I loved about the web when I first started building apps for it was that I could start with a single file in an editor and grow from there. Making a change, pressing F5 and seeing the change immediately was so liberating compared to long compile times and complex build systems. With your code carefully written so as to fail fast, you could often see failures in the live application faster than my Java IDE would pick up a type error in Java code (anyone remember the white menu bar of doom?).

I think it's a great pity that we've taken one of the web platforms major strengths - fast iteration times, and added so much tooling. We used to scoff at the fake stackoverflow question where someone asked 'how to do addition in jquery', but the sheer quantity of tooling that is normally used for projects has put us in a similar position.

Post reply on HN