This cones as no surprise to me, as TypeScript is a transpiled language. I know this is probably an unpopular opinion at HN, but I am a huge supporter of plain old JavaScript and have never really seen the benefits of DSLs like this. Coffeescript was especially pointless to me when I had to use it on a project. My reasons are simple: debugging becomes much more difficult when you add a layer of abstraction. It compiles to JavaScript anyway, and sometimes it does so in very odd ways that makes it difficult to understand the relationship between what you wrote and what it produced. IMO, straight JavaScript is more than adequate for most scenarios if you know the language well enough, especially with the powerful features built into the more recent versions. In my 20 years as a (mostly) front-end developer, I have not heard any convincing argument in favor of a transpiled JavaScript pseudo-language. Of course there are advantages, but most of these can be solved with better code organization and architecture.

I will say I don’t quite feel as strongly about CSS pre-processors like SCSS, which I really enjoy, however I still prefer plain old CSS for the same basic reasons.

My team started development of a React SPA. It was initially written with jsx. As we're starting to implement more, I'm finding more and more cases where the js code was wrong; property names that don't exist, wrong types being passed around, and non-existent props being used.

How do you suggest addressing this in a 10 dev team when developing in js?

Instead of writing types, you write tests.

You need rigorous tests though. At some point you end up with a hacked on version of typing. I appreciate that Typescript will tell me "this value might be null, and that function doesn't handle null" rather than writing a bunch of runtime checks to make sure the value isn't something invalid, and then writing tests to make sure those work.

You need rigorous tests anyway. Typescript is checking types only at compile time if I'm not mistaken and what it detects is only a set of problems. Yes it's nice that you can detect some types errors thanks to typescript, but is the development overhead worth it? With eslint, sonarqube, and tests, I think typescript is not that useful and annoying to use.

For example I contributed to Typescript's definitely typed project in the past. To make typescript more useful. But I ended up spending so much time writing type definitions. After all, I rather have some NaN or "undefined is not a function" exceptions during development.

You need less tests in a type safe language. Especially in a good one like reason / scala.js / elm. Typescript is just not very safe, its type system is unsound by design because compatibility with JS is their #1 priority.

Yes, you have the illusion of type safety but all you need is a slightly different JSON from an API to realize that typescript isn't that interesting.