I choose to avoid typescript for most of my projects and teams. There are some exceptions.
I have some fundamental guiding principles I apply to engineering, and I find that TypeScript violates these:
1) Reduce complexity
2) Don't be clever
3) Achievement over activity
4) Longevity
---------------------
#1 Reduce complexity
---------------------
Cross compilation introduces additional complexity with debugging and production support. Sourcemaps work fairly well, but often fail on edge cases - normally where you want to be debugging. I've found that JSDoc with good tooling gets 70%+ of the benefit of TypeScript without the additional complexity of cross compilation.
In the browser Javascript ecosystem, I aim to have what executes in the browser be as close as possible to what I've authored. Typescript works against this goal. This is even more important to me on the server side, where introducing a build step diminishes a lot of the value of having a flexible, dynamic environment like Node. If types are desired on the server side due to needed formalism (several problem domains are like this - banking, etc...) there are other languages/execution environments that may be a better choice.
------------------
#2 Don't be clever
------------------
Clever code is frequently a maintenance nightmare. Code should be clear, readable, and approachable. It should tell a story that's easy for anyone (even semi-technical folks) to read.
Typescript lends itself to "clever" and arcane types & structures that increase cognitive load and decrease maintainability, especially as the rules change.
----------------------------
#3 Achievement over activity
----------------------------
I guide my teams to focus on delivering business results and shipping software. I've seen code bases where up to 40% or more of the total LOC are nothing but types and structures to satisfy the compiler, not to provide features. In some cases, that's a good thing - where the business constraint is correctness over TTM, for example. If not though, it can be a company killer. You can end up shackled by your domain models, and small updates have massive cascading consequences.
I've seen developer's entire sprints consumed by tasks that are abstraction related, and don't provide business value. I've personally known several developers that have told me directly that they don't like shipping software, they just prefer to play with frameworks and development theories. While those are extreme cases, I know many more developers that fall somewhere around there. I'm not sure why, but I think Typescript encourages this soft of thing. I get a sense that the whole ecosystem is more about the software process than delivering valuable features to the users. Though those things aren't mutually exclusive, when taken to excess I've seen software process and tooling devolve into a weird sort of navel gazing that's a barrier to delivery.
------------
#4 Longevity
------------
I prefer to stick to standards. I also tend to avoid frameworks, I use Web Components as a component solution, and keep everything as vanilla as possible. I don't mind using stable libraries, like date-fns or lit-html, but I've been burned too many times by multimillion dollar boondoggles that result from framework churn.
I encourage my team to pick technologies and development methodologies that have a five year lifespan as a minimum goal. I have code I've developed in javascript that's been running in production for 15 years without needing a major overhaul, and with stable dependencies.
On the other hand, I've had TypeScript codebases that completely broke based on rule changes that came from a TS update, and required significant revamping within six months of being authored.
While I do think that TS can be beneficial for some projects and teams - specifically ones that require a high degree of formalism - most of the time I don't see it providing concrete business value. I see it consuming dev cycles for limited benefit.
I am looking forward to the optional typing that's currently a stage 1 proposal. I miss AS3, which I thought struck the perfect balance between static and dynamic typing. Static by default, but it was easy to opt out when being dynamic made more sense.
I strongly agree with #1 and #2 and that is why I like typescript. It keeps things simple for me. I can look at what a function's inputs and outputs are without having to guess. I don't have to worry about having an array of strings and then someone deciding to throw a boolean in the middle. I know what all the keys on my object are and what kind of values they will contain. Code I have never looked at I can quickly figure out the structure.
I have some fundamental guiding principles I apply to engineering, and I find that TypeScript violates these:
1) Reduce complexity
2) Don't be clever
3) Achievement over activity
4) Longevity
---------------------
#1 Reduce complexity
---------------------
Cross compilation introduces additional complexity with debugging and production support. Sourcemaps work fairly well, but often fail on edge cases - normally where you want to be debugging. I've found that JSDoc with good tooling gets 70%+ of the benefit of TypeScript without the additional complexity of cross compilation.
In the browser Javascript ecosystem, I aim to have what executes in the browser be as close as possible to what I've authored. Typescript works against this goal. This is even more important to me on the server side, where introducing a build step diminishes a lot of the value of having a flexible, dynamic environment like Node. If types are desired on the server side due to needed formalism (several problem domains are like this - banking, etc...) there are other languages/execution environments that may be a better choice.
------------------
#2 Don't be clever
------------------
Clever code is frequently a maintenance nightmare. Code should be clear, readable, and approachable. It should tell a story that's easy for anyone (even semi-technical folks) to read.
Typescript lends itself to "clever" and arcane types & structures that increase cognitive load and decrease maintainability, especially as the rules change.
----------------------------
#3 Achievement over activity
----------------------------
I guide my teams to focus on delivering business results and shipping software. I've seen code bases where up to 40% or more of the total LOC are nothing but types and structures to satisfy the compiler, not to provide features. In some cases, that's a good thing - where the business constraint is correctness over TTM, for example. If not though, it can be a company killer. You can end up shackled by your domain models, and small updates have massive cascading consequences.
I've seen developer's entire sprints consumed by tasks that are abstraction related, and don't provide business value. I've personally known several developers that have told me directly that they don't like shipping software, they just prefer to play with frameworks and development theories. While those are extreme cases, I know many more developers that fall somewhere around there. I'm not sure why, but I think Typescript encourages this soft of thing. I get a sense that the whole ecosystem is more about the software process than delivering valuable features to the users. Though those things aren't mutually exclusive, when taken to excess I've seen software process and tooling devolve into a weird sort of navel gazing that's a barrier to delivery.
------------
#4 Longevity
------------
I prefer to stick to standards. I also tend to avoid frameworks, I use Web Components as a component solution, and keep everything as vanilla as possible. I don't mind using stable libraries, like date-fns or lit-html, but I've been burned too many times by multimillion dollar boondoggles that result from framework churn.
I encourage my team to pick technologies and development methodologies that have a five year lifespan as a minimum goal. I have code I've developed in javascript that's been running in production for 15 years without needing a major overhaul, and with stable dependencies.
On the other hand, I've had TypeScript codebases that completely broke based on rule changes that came from a TS update, and required significant revamping within six months of being authored.
While I do think that TS can be beneficial for some projects and teams - specifically ones that require a high degree of formalism - most of the time I don't see it providing concrete business value. I see it consuming dev cycles for limited benefit.
I am looking forward to the optional typing that's currently a stage 1 proposal. I miss AS3, which I thought struck the perfect balance between static and dynamic typing. Static by default, but it was easy to opt out when being dynamic made more sense.