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

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

What randoms on the Internet think isn't useful to you, unless you want to make it your business a business-to-developer (B2D, a subset of B2C) company. Those tend to be difficult (difficult != impossible) as developers are cheap and don't efficiently time optimize. (https://miro.medium.com/v2/resize:fit:735/1*6Oyig2ACF-unC3R-...) Pricing is a dark art and not very scientific. it's not just take the cost to make the product and give yourself a profit margin and you're done. there's some advice at https://news.ycombinator.com/item?id=26553639 has a bit

Who you want to ask is though is people on developer productivity teams at large companies that have the budget to spend $10,000+ per year on a tool that will save the company > $10,000 (or whatever number you can justify using some back of the envelope math based on how often the checker needs to run how much faster yours is and how much that would save an organization with N developers.

B2B sales is difficult for a traditional software engineer (that would write such a tool in the first place to do) to do alone though, so you may want to seek outside help.

No.

Realistically you'll need to keep updating this. This means a one time payment won't cut it.

So the question becomes, will I pay 10$ a month for it.

Now if you could ship a better VS Code, not just a lazy fork, but something truly amazing, maybe I'd pay 10$ a month for that. It would need to be magic. Something to detect how projects should work. Help me with the 9000 different ways to configure a node js project , etc.

I don't think you could hope to do this with a team of less than 10 or so....

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.

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?

I'd pay for a 100x faster TypeScript parser / compiler with full AST access like https://ts-morph.com/ (that uses `tsc` under the hood, iirc). For just the typechecking part, no (I don't know if you can write a typechecker without going to AST, though).

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.

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.

Sure, I'd pay for it, but it'd have to be open source. You'd also be competing with STC (by the SWC creator, but it looks like it's dead for now based on GitHub history) and Static Hermes, which Meta is working on, both open source.

No, I've never had an issue with Typescript performance in any project. It's always been fast for me (M2 Max 32GB and a M3 16GB)

I use Webstorm though. Maybe it has better performance?