Then why use TypeScript at all? Just write js and put a TS definition on top. TS is a linter anyway. Now that will make the code easier to read, and in the end it is the code that will be interpreated by the browser or whatever JS runtimes.
Not really. TypeScript introduces optional static type analysis, but how you configure TypeScript also has an impact on how your codebase is transpiled to JavaScript.
Nowadays there is absolutely no excuse to opt for JavaScript instead of TypeScript.
What about debugging. Or with proper sitemap the code on the client-side can be debugged with the right map to the TS code?
Just feels like an extra layer of complexity in the deployment process and debugging.
With source maps configured, debugging tends to work out of the box.
The only place where I personally saw this becoming an issue was with a non-nodejs project that used an obscure barreler, and it only posed a problem when debugging unit tests.
> Just feels like an extra layer of complexity in the deployment process and debugging.
Your concern is focused on hypothetical tooling issues. Nowadays I think the practical pros greatly outnumber the hypothetical cons, to the point you need to bend yourself out of shape to even argue against adopting TypeScript.
