Not directly, but it becomes harder to reason about performance unless you're familiar with the TS compiler and/or it's output. Once you identified a performance issue related to the JS VM(s) you're targeting, it's also harder to resolve the issue. This is true for every "compile to JS" language and TS is no exception.

98% of typescript compilation is just dropping the type annotations; Babel for example outputs TS almost exactly as written. There’s no voodoo compiler passes going on unless you add them on top of Typescript. There’s no practical performance difference from JSDOC comments unless you’re using tsc to target ES5 or below; and in that case vanilla ES2020 would need a similar amount of Babel shenanigans to downlevel iteration.

Realistically, that simply doesn't apply to TS, because the conversion to JS literally just removes types.

Not always, because certain operations that look trivial in TS involve more code in JS, e.g. the widespread `?.` operator. The code is usually trivial though.

It's Flow that just allows to remove any type annotations; there's no compiler, only typechecker.

You're mistaken. Optional chaining is a JavaScript feature[1]. The stated goal of TypeScript is to be valid JavaScript when the types are stripped away. That's why they have functionally removed namespaces and they want to remove enums. They're the only language features that are actually compiled instead of just stripped.

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Indeed I'm mistaken; this only happens when the target JS version is old enough not to support that.

In theory this might be the case, but in practice all the TS compiler needs to do to produce valid JS code is strip the type declarations from the input. There are a couple of minor exceptions (enums don't exist natively in JS, and are replaced with objects, and things get a bit more complex if you use decorators), but in general idiomatic Typescript code should look the same as equivalent idiomatic Javascript code.

This gets a bit more complicated in some setups because the typescript compiler can also transpile modern JS/TS code to older versions, doing a similar job to Babel, but this doesn't have to be the case, and in practice this tends to be fairly orthogonal to the question of Typescript: you can compile to older versions regardless of whether you use Typescript, and you can use Typescript regardless of whether you compile to older versions.

So in practice, there will be no difference between a Typescript program and an equivalent idiomatic Javascript version, because Typescript is just Javascript with syntax for type hints.

For the most part typescript does not significantly change what you input (except, of course, by stripping type annotations, type declaration, and type imports) unless you request transpilation to earlier ECMAScript versions or a different module format. (It will also by default transform TSX to ECMAScript, but it can be configured to output as JSX instead, which could later the handled by a different JSX transpiler if needed.)

The main exceptions are enums, and decorators, both of which perform straightforward transformations. My understanding is that adding new such features are forbidden as the TypeScript team considers them to be historical mistakes. If new syntax is added in the future is should be such that it can be mechanically stripped, leaving the obvious underlying JS behind.

There also exist some historical features like namespaces or const enums that have long been considered essentially deprecated by the team (not marked as such in the documentation, as there are no plans to actually delete support for them, but they won't work correctly in isolatedModules mode for example). In practice those features are not used in new codebases since project templates will be configured with isolatedModules enabled.