I used to think this way too, but working over the years with TypeScript has gotten me so accustomed to it that it’s now the other way around. I feel much more productive in TS in general.

With TS its like you’re writing the unit test and your code at the same time, and if your types are expressed well enough you can also skip the compile+run+verify step.

I’ve had cases where I would spend days just writing code, refactoring and iterating, without building the project once, compile it at the end, and have a complex feature work correctly on first try, passing all the functional tests.

It’s like I have a pair working with me constantly compiling my code and pointing out syntax and interface errors while I concentrate on the business logic and big picture stuff.

When I go back to JS it’s as if I now have to do all that manual labour too, as well as constantly write and run unit tests myself to make sure what I write actually works.

Though it definitely took some time to get this comfortable with the TS type system.

Perhaps much like the parent, I want to create without the foundation of TDD or unit tests, so I find the mixture to be expensive in the cases I'm typically working.

One of the things I learned, not from TypeScript but from other languages with type systems that work similarly, is to minimize the use of type decorations and let type inference do most of the heavy lifting.

It took some getting used to because things end up a bit less obvious, but I found that with the IDE's syntax highlighting capabilities, actually inspecting the inferred types isn't as much of an issue. And then you spend less time typing out type names.

Huh. I recently built a language parser in TypeScript and it was a very positive experience. As just one example, discriminated unions for AST nodes worked great.

Always tempted to experiment again for a day or two.

Maybe that's it. I've never felt bad about settling for 95% of the benefits of static typing and slapping any/unknown on the edge cases.

For my company production code I definitely spend way too much trying to implement the correct types, however for side projects and MVPs I do quickly what I have already learned or just sometimes if it's too complicated I'll just go with "any" styled solutions or similar things. I think using TypeScript flexibly for prototypes helps me do that "first compile test" will work out of the box very easily.

This isn't a fault of TypeScript, but any language. Trying to predict the future, trying to predict and eliminate technical debt, in a rapidly developing product.

But it is the fault of TypeScript for having such an obvious path for falling into that trap. Part of what it means to have TypeScript code is to have typing files.

Part of good language design is attempting to minimize bad programming habits. In this case, a language with a HM type system would avoid the issue all together, while affording the same productivity gains from having static types.

This isn’t actually a fault of TS, it’s an explicit goal. They design the type system not to guide usage but to make existing usage explicit and trustworthy.

The places where the type system encourage rabbit holing are almost always where bad types/APIs are already prevalent. Where you’re starting at the type level and don’t have an inclination to allow all manner of dynamic nonsense it’s not that different from types in an ML-family language.

Don't treat types as theorem provers, treat them as formalized docs - getting dirty with dynamic under the hood is perfectly acceptable to me (say you're doing some metaprogramming - typing that out is usually a lot of effort for low gain) - the types just help define intended use.

In code consuming types I relie on inference 80% of the time, sometimes I need to specify generics, if it fails I do dirty casts, if that fails I do dynamic blocks.

Yeah, see how it goes when your system gets past about 20kloc. In my experience working without types starts out great but you soon hit a wall.