I taught myself Turbo Pascal in middle school (34 years ago) and C/C++ in high school. (Both typed). Over the years, I have done programming with C, C++, Java

I taught myself Turbo Pascal in middle school (34 years ago) and C/C++ in high school. (Both typed). Over the years, I have done programming with C, C++, Java, C#, PHP, Python, OCaml, Lua, Nim, Golang, Rust, Objective-C, Flash, Bash, D, Scala, TypeScript, assembly, PL/SQL, F#, and a few that I am forgetting. Compile time type checking can definitely make things easier. But for dynamic languages that I have been programming in for many years to have types shoehorned into them as an afterthought feels like a kludge. And it's a tradeoff. I got used to developing in Node or Python with vim without auto completion (although I had those things as a kid in IDEs for other languages and they can be great). And without compile time type checks. You can pass JSON around and literally never do a database migration. This stuff will lead to more runtime errors initially, but also means more streamlined code. And you have to do thorough testing regardless. TypeScript might be a choice for a large project with several developers. But I would also argue that an even better choice would be just to use a different language that has the typing system you want built in rather than awkwardly bolted on. What I see in most TypeScript projects is a half-assed attempt that still results in run time type errors, but with the added "benefit" of an awkward bolted on typing system and the need for more tools as well as losing any dynamic benefit. They drop the idea of using JSON and make everything related to the database compile time checked if possible. I'm not saying that those checks can't be useful but if are going that route it would make more sense to just drop the dynamic language. Having all of the dynamism can be a convenience and save you time and effort in other ways. But not if you treat it as a poor man's static language and shoehorn in types in a half assed way using a traditional database. Part of this is that people think software engineering is about your choice of stack or adding processes to development. What matters most is probably the feedback loop between the users and the developers. Starting with the requirements engineering. Second to that would be details of the software design and organization. Leveraging existing code effectively can be key. Using descriptive but relatively concise identifiers, short functions, good code organization. But diving into and evaluating all of that stuff in detail takes effort and a lot of skill and so many make snap judgements based on surface level processes or tool selection.