Even Rust is still nominally typed, which means you have a lot more boilerplate.
1) Declaring functions with typed output and types on the arguments. This allows you to create large architectures with minimal confusion. It allowed me to write an OS in TypeScript.
2) Declaring message payloads as object interfaces. This imposes a set of predictability and consistency in your services. It's so obvious in hindsight, but before TypeScript I was putting all kinds of safe guards around my service payloads to account for unpredictability that really impacted how the application scaled.
I think where people discover the most challenges migrating to TypeScript is that it exposes some level of unnecessary complexity in prior practice and some people do incredibly weird things with their type definitions to make it feel more OOP.
The authors praise--and begin with an example from--D3.js, and work through handrolled dependency injection, aspects, and test-driven development with Jasmine.
Truly understanding `this`, .bind, .apply, and .call may be essential to a mastery of (vanilla) Javascript.
(For those who don't know, the tweet author is the Rails creator.)
But on the other side, writing code consuming TypeScript libraries is amazing. Seeing all the type information in the IDE reveals so much, resolves so many questions, and builds confidence so quickly.
The other issue with TypeScript is that tooling is all awful & terrible. Tsconfig is a drag. There's a serious lack of good conventions to follow & tons of ad-hoc stringing shit together. Ideally libraries should output both esm & cjs but typescript literally doesn't support it & you have to run typescript twice, so now you maybe are introducing yet more new tools like concurrently if you want to do a good job. Oh and now your "watch" script is even more janked up too. Deno does a good job of making this pain all go away, but in general TypeScript is one of multiple layers of tooling that simply sucks, that thieves energy & attention.