I agree, and I consider TypeScript to be twice as fast to develop in as plain JavaScript just because you don't need to:

* Look up member names

* Look up object hierarchy structures

* Run code (or tests) to verify that you've done the above correctly

When the compiler knows the types, it can bring your code up to 90% correct. Half the time you don't even need to specify types: TypeScript can guess them from context.

You need to specify parameter types and return types; if you're declaring a variable without initializing it, or assigning it an empty array or object, you need to specify its type. Other than that you generally get type inference from TypeScript (at least as of 2.0).

It goes beyond just catching bugs. Large code bases written in statically typed languages are easier to understand.

I've worked on large production codebases in the past, for servers written in both Java (at company [a]), and JavaScript with Node.js (at company [b]).

The Java codebase was much easier to read, understand, navigate around, and debug. If a function took an argument "SomeClass foo" I could look up "SomeClass" and know exactly what it was.

In the Node codebase, if have argument "foo", you're lost with no easy way to figure out exactly what this "foo" is. You would have to run the code, set a breakpoint, and inspect "foo".

In addition, JavaScript encouraged a lot of bad coding practices that almost made me want to cry.

In the Java server, we used a JSON library where you would annotate a class, and the library would construct an object for that class. This guaranteed the JSON was well-formed, among other things.

In the Node.js codebase, people would pull something out of Mongo, chuck it in a variable "data", and then do "data.foo.bar[1].qux". (Yes, the "[1]" is real.) It was terrible.

The company that used Node.js had far less reliable code overall, and their services (written in JavaScript) would crash frequently, most commonly due to type errors.

And this is just a tip of the iceberg. There were so many problems that attributable to the choice of JavaScript as the language for a large, complex back-end system, and the failure to use any tool for type checking (like Flow), in addition to bad coding practices.

[a] Amplify Education, Inc. https://www.amplify.com/

[b] Lifion, a division of ADP. http://www.lifion.com/

Honestly I think the bug catching aspect of static typing is its least useful property. (Useful, but not like, amazing -- you can write assertions on a type in a dynamic language). I think the good thing about static typing is it makes a code-base much easier to navigate and much more self documenting. I spend most my time navigating other peoples code. I know you can get most of the reliability of static typing with extensive test suites etc., but that doesn't help my IDE and it doesn't let me look up parameters at a glance. I used to be firmly in the dynamic camp, but having to maintain other people's javascript definitely made me do a 180.

Maybe the initial write is faster, but any refactoring strongly favors static type systems in the speed department. Even an extremely well tested dynamic code base will have a significant disadvantage for refactoring because the tools can't catch all the small details and you'll have to iterate over and over again until tests pass.