If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough.

People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously.

How to say. There is no way just adding typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS.

> Can you give a concrete example where typescript is a blocking issue for your development?

Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit.

Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.

Do you still put your seat belt in your car after 5+ years of driving experience? If yes, would you say that you do that because your driving skills are "plainly not good enough"?

Typescript allow you to spend less energy on minor issues like typos and more energy on design. It also provides you with the ability to reason locally about some code. When you inspect a function in js, you cannot know what are the contracts that it has to deal with. To be sure you have to unravel all the calling and called functions.

Typescript also enables better intellisense.

About your issues:

- I never had tsc dying on my hand in 5 years.

- About the transpilation noise: it can be as noisy as you want. Have you checked the default result for the es6 target? It litteraly look like your source code with only your type signatures stripped. The noise comes from the transpilation to lower versions and bundling and those are independent of typescript.

Considering typescript compiles down to JS, and incredibly readable JS at that, the fact that your developers are unable to debug the JS directly may indicate that they are not as amazing at JS as you may believe they are.

> If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough.

What about linters, static analysis, code highlighting, IDEs? Should we skip those too? Should I dig out my "made with notepad" badge?

Types and good static analysis tools allow me to focus on more important things, such as business logic, scale, planning. We don't pay developers for mental gymnastics, but solving real world problems.

Of course we do that, and I looked at Flow a few times.

But typing errors are such a minor thing in comparison to everything else, than "everything else" is of much higher on the priority list

When I am writing plain JS I often end up having to write loads of tests to check that I don't to wrong things with types. Did I remember to consider null/undefined? What if I sent in something totally different?

With TS I don't need to spend as much time with these types of tests. I just let the compiler do it for it. If my function says in it's signature the argument can't be null I don't need to do null-checks.