Preface
In 2023, Typescript is rarely questioned as an important tool for modern JavaScript developers, but one of its biggest limitatio...
For further actions, you may consider blocking this person and/or reporting abuse
Hey there @nicklucas ! I'm on the core team at ts-rest.com. We've actually done a very similar analysis here: github.com/ts-rest/ts-rest/issues/162. We use Zod for a lot of our implementation. Curious to see if you've enabled
strict(more specifically,strictNullChecks) in all of yourtsconfig.json/compilerOptions?If not, I implore you to follow the steps here ts-rest.com/docs/troubleshoot#why-... (you don't have to use
ts-rest) and see if it improves your TS performance.strictNullChecksis actually required by Zod github.com/colinhacks/zod#requirem..., and the reasoning is here: github.com/colinhacks/zod/issues/1750I suggest rethinking posting this article if you haven't enabled that compiler option for every
tsconfig.jsonin your monorepo, as that would lead to an unfair comparison against the other libaries.Thanks for reading!
Hey Michael, yes these benchmarks were all done using strict=true and it's the same at work. Strict mode just makes TypeScript that much better. Good question though as I didn't think to bring it up :)
Have you tried SureType?!
npmjs.com/package/suretype
We maintain a whole repo of runtime benchmark tests here:
github.com/moltar/typescript-runti...
Didn't know about Light Type, added an issue here:
github.com/moltar/typescript-runti...
Looks fantastic! Any plans to add comparative benchmarks for type-checking in the spirit of this article?
Light-Type is very much still an experiment, but I'd love to see it incorporated, especially if it goes to a release 😄
Do you mean this:
If so, there are a few issues and discussions surrounding that. No clear consensus yet on how to achieve parity across all packages. Basically there is a debate whether we should have a common denominator or if we should open up to different test cases. Opening up to different (per package) test cases can open a can of worms.
You can find an awesome, and very thoughtful response by @sinclairzx81 (the author of typebox) here:
github.com/moltar/typescript-runti...
Ah I mean, my understanding from looking through your results is it's about run-time performance of the parsing of data. This piece here is about language server / compile-time performance of typescript itself. I believe they're both very important in their own ways.
Zod has put a lot of effort into being pretty fast at parsing and that shows in your suite, but it's demonstrably bad at producing performant typescript inference. I've worked on a benchmark suite lately which demonstrates this and could easily be extended to more libraries
Ok, I understood your point. Yes, I thought about TS parser performance. I think it would be a great addition to the suite. Please create an issue with any thoughts or suggestions you may have to foster a public discussion. We would appreciate your existing knowledge transfer so we can make the benchmark suite more robust.
Feel free to submit a PR. Use a previous PR for submission as guidance. Even if it's not fully ready, it's ok. As long as it's a published package, it's fair game. At least that will give you some feedback how it stacks against the rest of the ecosystem!
Issue: github.com/moltar/typescript-runti...
I highly encourage folks to checkout the little talked about lib SureType... it is amazingly fast and a pleasure to use.
npmjs.com/package/suretype
How does this affect time-to-autosuggest (considering TS caches a lot of stuff)?