4 ms·

You are wrong, and the statement that it is based on dogmatism is completely baseless. A couple years ago, the Deno team switched from TS to JS for performance

You are wrong, and the statement that it is based on dogmatism is completely baseless. A couple years ago, the Deno team switched from TS to JS for performance reasons because compiling the TS code became painfully slow. This was an entirely practical reason. Similarly, a lot of JS package authors choose to use JS in conjunction with JSDocs, type def files, and tsc (see: Preact).

e12e 4y ago
> 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_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/mobilebasic#heading=h.cx5nx247bag https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...
- kevinfiol 4y ago
  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.
  - jakear 4y ago
    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.
spankalee 4y ago
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.
- kevinfiol 4y ago
  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.

e12e 4y ago

> 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_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/mobilebasic#heading=h.cx5nx247bag https://docs.google.com/document/u/0/d/1_WvwHl7BXUPmoiSeD8G8...

kevinfiol 4y ago
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.
- jakear 4y ago
  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.

spankalee 4y ago

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.

kevinfiol 4y ago
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.