Live data from Hacker News

Ask HN: Would you pay for 100x faster TypeScript type checker?

news.ycombinator.com

1–10 of 19 posts

Ask HN: Would you pay for 100x faster TypeScript type checker?

#1
As the title says, would the benefit of having a let's say ~100x faster TypeScript type checking be so great that you'd pay for it? If so, how much? I'm currently evaluating whether it's worth to reboot TypeRunner [1] and bring enough value to the people. I'm not interested in open-sourcing it as it's a lot of work for a single person and I did/do already too much OSS.

This is in contrast to existing solutions like SWC, which do not do any type checking, but just transpiling.

[1] https://github.com/marcj/TypeRunner

Re: Ask HN: Would you pay for 100x faster TypeScript type checker?

#2
I love the Typescript ecosystem and language but am increasingly disillusioned with how slow the type checking is. When you start layering in libraries that use a lot of inference or complex types even my desktop battle station can slow to a crawl and take several seconds for intellisense or type checking to come in or just outright crash.

The number of hours I've lost to this and having to restart the TS server in VsCode is definitely not trivial. If this had parity with TS upstream and delivered a meaningful improvement to quality of life in my IDE I'd happily pay 10-20 dollars a month out of my own pocket for it.

Its crazy that as an industry we've accepted performance regression in our tools like this. Our recommended minimum RAM for our TS monorepo at work is 32GB just to be able to handle VsCode, Docker etc...

Re: Ask HN: Would you pay for 100x faster TypeScript type checker?

#3

I love the Typescript ecosystem and language but am increasingly disillusioned with how slow the type checking is. When you start layering in libraries that use a lot of inference or complex types even my desktop battle station can slow to a crawl and take several seconds for intellisense or type checking to come in or just outright crash. The number of hours I've lost to this and having to restart the TS server in V…

I’m curious about how VSCode and WebStorm compare in TS perf.

Re: Ask HN: Would you pay for 100x faster TypeScript type checker?

#5
No. During development, Bun or Esbuild or any other fast type-stripping tool is good enough for rapid iteration, and the LSP type checking is fast enough and good enough for me. I leave tsc running in watch mode as I work, and it is damn slow, but I rarely am doing anything where I’m actually waiting on it.

Re: Ask HN: Would you pay for 100x faster TypeScript type checker?

#7
No because at longest a tsc compile job on an extremely large application of hundreds of files might take at most 13 seconds. Then on top of that I typically just execute type checking in my editor and SWC in my build. The only time I run a static tsc job is just prior to code commit.

Re: Ask HN: Would you pay for 100x faster TypeScript type checker?

#8
Where I worked full TypeScript compilation in the monorepo would take an hour or more. But that would be kinda rare. Using project references and heavy CI caching and remote caching we were able to type-check parts of the repo with confidence, so IDEs were performant in multi-million-line TypeScript repo.

This is a very likely customer of what you're offering but I doubt it would be an easy sell. Specially that there is always risk of drifting from mainline tsc when using 3rd party compilers

You'd not be the first one to try build a faster tsc. Did you do a deep dive of why they all hit a wall with TypeScript complexity?

Re: Ask HN: Would you pay for 100x faster TypeScript type checker?

#9
Perhaps. In our huge project it slows the team down a bit. It could even be worth having a faster precheck / prebuilt step for the CI to fail fast. While money is less of an issue, configuring another tool in legacy monorepo might be the biggest blocker.

Re: Ask HN: Would you pay for 100x faster TypeScript type checker?

#10
post #3

I love the Typescript ecosystem and language but am increasingly disillusioned with how slow the type checking is. When you start layering in libraries that use a lot of inference or complex types even my desktop battle station can slow to a crawl and take several seconds for intellisense or type checking to come in or just outright crash. The number of hours I've lost to this and having to restart the TS server in V…

I’m curious about how VSCode and WebStorm compare in TS perf.

Why should they be different?
Post reply on HN