> A couple years ago, the Deno team switched from TS to JS for performance reasons because compiling the TS code became painfully slow.

It doesn't seem that performance was the driving factor, but the ability to keep code idiomatic?

https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...

I may be misreading, but from the first two bullets under "Problem":

> Incremental compile time when changing files in cli/js takes minutes. This is crushingly slow and painful to modify.

> The typescript organization/structure that we're using in cli/js is creating runtime performance problems.

Either way, my point is that there are very practical non-dogmatic reasons to use JS over TS.

This decision turned me off from Deno in a big way. It's as if they actively refused to look out to the community to see if the problems were solvable before throwing in the towel. It's quite possible to have instant incremental updating of TS projects, when I was a developer on VSCode (a much larger TS/JS project than deno) a change to the source code would be reflected in my dev build in less than 100ms.

Deno integrating TypeScript at all was a big mistake, but that doesn't mean that TypeScript at build time isn't a god idea, or that transpilation can be extremely fast with tools like esbuild.

That's not the point I'm making. I use esbuild often for TS development tooling.

But if you're building developer tools or libraries and want the output to be optimized for the end-user, introducing a middleman like tsc or esbuild can have tradeoffs. This is likely what the ESLint team considered.