I mostly agree, I just wanted to point out that it's funny (to me, anyway) that the same argument applies in both cases. If you don't have type scripting, you also give up a certain level of developer productivity.
When you have to hunt down type bugs a linter or compiler would have caught, you can waste large amounts of time. I think type bugs are usually fast to find & fix, and only occasionally take time.
I like using a type checker of some sort (Closure compiler is probably my fave) for release builds, and leave it off for dev builds. I like this option even more than TypeScript, because you don't necessarily need to have a build step for running dev code at all. Then you get the best of both worlds, you can iterate quickly without adding or checking types, then you can spend a little time checking types before merging a branch. Any time a mysterious bug pops up, first order of business is check types.
Even for React, I'd still rather have the option to type check than not have it. Flow is nice because once setup & running, it's really fast. I've seen it catch long standing type bugs that nobody thought were there.
I would bet money that you actually write less code with Typescript than regular javascript because of all the streamlining and shortcuts. And with the type inference you almost get static typing for free.
I hear this argument come up frequently against TS and all I can say is I'm fairly sure it's from people that haven't used it.
Typescript feels like a step in a completely different direction. The problems that TS tries to solve have other solutions. Solutions more idiomatic to javascript development. Redux style architectures, grouping code by feature, libraries over frameworks, GraphQL and so on. And these solutions are solid and dependable. Unlike the made up brittle and often incorrectly defined types that Typescript and Flow demand. If you want to use Typescript, then I hope you really really REALLY like Generics, because they're absolutely everywhere in Typescript. They're the solution to the fundamental flaw with TypeScirpt, it wasn't designed with the actual job that Javascript does in mind.
It's Javascript for people who don't like Javascript and don't care to learn it. Well that's fine, each to their own. But people sing it's virtues without pointing out any of the flaws in both the approach or the implementation (maybe because they simply don't see anything wrong), and that really rustles my jimmies.
Not a bad one, but very intentionally different.
I personally prefer a style/practice that doesn’t work well with TS, but I appreciate it exists and typedef files for libraries are very nice for developing in things like VSCode.
IMO the opposite is true; without types you give up some developer productivity in the form of time spent writing tests and debugging issues that the type system would obviate automatically. In my view, loose typing adds the illusion of productivity because the developer might presume they are working faster because they don't have to reason about type restrictions, however they simply end up enforcing type restrictions manually (and relatively poorly compared to a solid type system) using "typeof" and "instanceof" checks throughout their code. In general, assigning multiple types to the same variable is considered a code smell anyway, so strict typing simply enforces what is already considered a best practice.
Of course, this doesn't mean that choosing typescript in particular is always the right engineering decision, but, all other things being equal, a strict type system is almost always preferable to a loose one.